But it irritates me when I need to get at gpg from a web application, and can't just use a "libgpg". I have to fork a gpg process, setup file descriptors just right, write input to a pipe, wait for input on another pipe, and then parse the result
It boggles the mind that a perl programmer, of all people, would think this. The relevant code for the above is generally something like:
my $data = `gpg --decrypt --passphrase=$PASSWD $FILE`;
or:
open INPUT, "gpg --decrypt --passphrase=$PASSWD $FILE|";
while(<INPUT>) { ... }
The incredibly tight integration with external programs (e.g. the code to "setup file descriptors just right" consists of one byte!) is the very essence of what makes perl great and special. I'm just dumbfounded here. He likes perl but doesn't understand how to fork a process?
I mean, the whole premise of the point is counter to the perl philosophy, which is that you're already on a great and useful platform and just need a tool to tie things together nicely. If you want a single platform designed around the idea that all meaningful tasks are available in a library without leaving the sandbox, you are looking at Java or .NET, certainly not perl...
$PASSWD was available to everyone on the box anyway. You stick it in memory, it's readable. That's the way life works. You probably stuck it in a database too, right? Did you lock down the socket from local users? Probably not. Did you store the database password off-line? Probably not, because you wanted unattended startup to work.
The bottom line is that if you want to do password storage in your web app that is secure against local users, you have vastly more work to do than just finding a CPAN library somewhere.
Just because security by obscurity is not a barrier you should lean on doesn't mean that it lacks value in combination with other measures.
Script kiddies will struggle to isolate data from memory in order to get passwords, particularly if they can't get binaries on the machine and it has no compiler. On the other hand, they will have no trouble using a copy and paste ps usage.
And when I say script kiddies, I also mean the sort of 9-5 culture, corner-cutting production support teams that exist in some organisations and who might have accounts on shared hardware that your application runs on. Do you really want to make it easy for them to do favours for people on the business side who want passwords they shouldn't have?
> The bottom line is that if you want to do password
> storage in your web app that is secure against local
> users, you have vastly more work to do than just finding
> a CPAN library somewhere.
> Just because security by obscurity is not a barrier you should lean on doesn't mean that it lacks value in combination with other measures.
Damn straight. Check out the DNS spoofing defences - using random ports to issue requests on. There's a known limit to port numbers, and you could probably circumvent it with massive amounts of traffic, but using an unknown port number makes it hard enough that performing that kind of attack is significantly more difficult.
I think you mean you agree with me, no? Unless you're really arguing that simply using a CPAN library renders your application secure to all attackers? I think you're arguing against the converse of what I stated, not my actual point.
OK, just curious: how is the posting of judgemental one-liners unrelated to the subject at hand somehow less of an etiquette violation than a perfectly harmless (yet responsive and topical) rhetorical snipe? I mean, as flames go this was pretty mild sauce. Can't you spend your time policing some of the legitimate flame wars that pop up here instead?
Say UID 100 is running PID 200 which has "my password" in memory. How does UID 300 read the memory of PID 200?
If it requires a security flaw, I don't think it's fair to compare to the ease of using 'ps' ... if it doesn't, please explain so I can learn something today. :)
On a linux box, read /proc/200/mem. Or just allocate a bunch of memory and force it to swap out, then read the swapfile. Season liberally with local root exploits if needed (these come in bucketfuls on most unices). This is a classic attack: while it's not terribly practical, it's a whole lot easier than trying to brute force the password stream.
I'm not saying local-attacker password security can't be locked down securely. Simply that doing so is a much more complicated proposition than "use a library". In practice, most web applications are not secured against hostile local users. I'm not sure I've ever seen one that was. So to my mind, ruling out some of the most powerful tools you have (perl's IPC facilities) in a vain attempt to achieve a security level that the rest of your architecture doesn't support seemed silly.
Is your security analysis assuming that the attacker is running under a different uid than the web server? Why on earth would you do that?
I'm not sure where all these security discussions are going. My point was simply that taking the passwords out of the command line of gpg was woefully insufficient to secure them (note, again, that they're going to be stored in a database whose password is stored locally in a file), so using "security" as a reason to avoid perl's elaborate and very robust IPC facilities was a poorly grounded argument. Nitpicking about whether one (!) of my examples matches the original author's security assumptions is very much missing the point.
To get back to perl: note that you can feed the password to GPG via stdin if you want with just one extra byte to the open string, and a call to autoflush() and print().
Is your security analysis assuming that the attacker is running under a different uid than the web server?
Well, that's just what my example question above said.
Why on earth would you do that?
To avoid them reading the memory? It's pretty common for shared hosting to have each user running on their own local port and a reverse proxy listening on 80, just so that each user gets the benefit of the basic UNIX security model (we assume trust in the admin, of course). I guess I don't understand the whole password in a file thing, either. If those have proper permissions then the only person who have to trust other than yourself is root. Seems better than nothing to me.
Is your security analysis assuming that the attacker is running under a different uid than the web server? Why on earth would you do that?
In a secure shared hosting environment applications do not run as the web server UID. They run as the owner of the virtual host. Apache does this with mod_suexec.
Are you doing it differently? Why on earth would you do that?
The unix security model isn't amazing, but it does a reasonable job of protecting you from users other than root -- putting cleartext passwords in command line arguments is one way of throwing that away.
Then again, as you seem to be saying, manipulating cleartext passwords are usually a bad idea in the first place
It was a "trap" because the data is still available in memory either way? Are you serious? Oh, and if anybody has any clever retorts to this comment, I'm actually laying traps right now expecting you to say just that. Be warned
The idea is that in perl is very usual and common place to call externals programs, the thing is that you don't need to setup the filedescriptors manually as jrockway says he does in the article.
I'm a high performance systems researcher, not a professional developer. If I could write my code by just combining existing libraries, then it wouldn't be research.
Load imbalance in a single node in a distributed stream processing system and language, and programming models and code generation techniques for the Cell processor.
Not necessarily. What I don't like about the "programming is about gluing libraries together" approach is that you have to deal with a plethora of hidden costs:
1. Finding the available libraries for the job. There might not even be one if you're doing something somewhat novel. Or there could be a huge number of them, most of them crap.
2. Evaluating the libraries found in step 1. You might find that no library is a superset of the others, that for example there's 3 of them that each tackles 1/3 of the problem in exactly the way you want but you have to compromise and choose only one of them.
3. Dealing with the library's bugs, limitations, misfeatures, incompatibility with your usual programming style. To fix those problems you either have to dig deep into a codebase that's not even your own (if you even can), or you take the passive approach and contact the vendor to ask them to please fix the bug or implement the feature and then wait 2 weeks or 2 months or 2 years or foverer until it gets done.
Whereas with the "I have a strong NIH syndrome and will do everything myself" I have lots of up-front costs but at least I know pretty much exactly what they are and the problems that come up are fun things like: "oh, I need to master this super powerful technique", not boring ones like: "oh, I need to get in touch with the maintainer of this library to implement a new feature I need if he so chooses".
Your #3 hidden cost is nonsensical in the context of CPAN. The libraries are Open Source, and usually heavily tested by both automated tests and hundreds or thousands of users, and if you grok Perl enough to roll your own, then you grok it enough to fix a bug in the library. You'd have ten times the number of bugs to fix if you wrote it yourself, at least I would...maybe you're just that much better of a developer than I am.
As for #1...CPAN search works pretty well. Google can also help. Obviously every hacker is doing something somewhat novel or else they would just be using existing software...but the point of CPAN is to insure you don't have to do the boring crap over and over again. Session management? Done. Database access? Yep. Payment processing? Sure. Templates? Definitely. Internationalization? Well, you still have to hire the translators. Processing and spitting out XML, HTML, YAML, JSON, RSS, etc.? Of course.
So, either you're writing all of this from scratch, or your software is anemic and lacks basic APIs and data export capabilities and interoperability and good security, etc. I'm sure your app will kick ass when you finish it two years from now.
As for 2...does evaluating a couple of competing libs really take longer than writing one from scratch? Maybe, for some classes of problem. But there's a lot of stuff that just takes a lot of code to accomplish.
"oh, I need to master this super powerful technique", not boring ones like: "oh, I need to get in touch with the maintainer of this library to implement a new feature I need if he so chooses".
I don't even really know how to respond to this one, but I'll take a stab at it. Is a template engine a "super powerful technique" that you're excited to figure out? Payment processing? Session handling? How about a test harness? Form validation? Having a good selection of available libraries saves you from the boring crap, not the other way around.
CPAN might be perfect now, but it wasn't always golden. The fact that every module relies upon dozens of other modules meant that your life sucked when one of the dependencies crapped out during an ubermodule install. You'd have to trace down where, what and why the dependency was broken and the idiosyncratic nature of Perl didn't help much with fixing things. Tearing my hair out during another aborted CPAN install was one of the reasons I switched to Python in 2001. Python came with its own set of issues but at the time they seemed more appealing than dealing with amateur hour on CPAN.
My post is self-contained, it didn't reference CPAN or the article.
Hmmm...That seems a little odd in the middle of a conversation about a blog post that talked about pretty much nothing but CPAN. I guess you can talk about anything you want, but you can't possibly expect us to know you're not talking about the same subject as everyone else.
I find your adversarial tone inappropriate.
I'm sorry you feel that way. I'll try to tone done the sarcasm in any future replies to you.
Well, in your first post you just thought I was attacking CPAN, while the berserk part is when you combine your two posts together.
"maybe you're just that much better of a developer than I am [...] So, either you're writing all of this from scratch, or your software is anemic and lacks basic APIs and data export capabilities and interoperability and good security, etc. I'm sure your app will kick ass when you finish it two years from now. [...] I don't even really know how to respond to this one, but I'll take a stab at it. Is a template engine a "super powerful technique" that you're excited to figure out? Payment processing? Session handling? How about a test harness? Form validation? Having a good selection of available libraries saves you from the boring crap, not the other way around."
Such extreme condescension stemming from an misunderstanding of what I was saying I consider "going berserk", yes.
"I guess you can talk about anything you want, but you can't possibly expect us to know you're not talking about the same subject as everyone else."
"I'm sorry you feel that way. I'll try to tone done the sarcasm in any future replies to you."
What a beautiful paragon of passive-aggressiveness. I applaud you!
Because, though this is a relatively sober and even-handed example of the genre, it still inevitably contains howlers like this:
Search for "rails". Most of these programmers will depend on one library, Rails, but then get the rest of their code by cutting-and-pasting from blogs.
Which is hardly surprising. This is the canonical problem with articles like this one: The guy doesn't waste time tinkering with Ruby, because he's busy being productive with Perl, so why should he be expected to know anything about how the Ruby community works?
(This is why I try not to write about Python except to assert that it must be one of the best languages in the world: I'm literally unsure how to write hello, world in Python, but smart people use it all over the place, so deference and politeness forces me to assume that it's utterly perfect until proven otherwise.)
Anyway, I'll help out by saying that I think jrockaway's point still stands, albeit on fewer legs than before: Perl is a considerably older language, its community is more experienced, it's (among other things) a traditional tool of system administrators -- who are, in my experience, relentlessly pragmatic people who crave stability, reliability, and clear docs -- and so it has had a lot more time and incentive to organize and standardize its packaging and documentation systems. Ruby does have docs difficulties, as do many open-source projects which have recently experienced explosive growth.
No. He has. So have I. He's commenting on the reality of a culture dominated by fanboyism and a framework advertised on the basis of being "full stack" which to naive eyes can seem to be "everything you need".
rubygems -enables- granular reuse of libraries, and many ruby people take great advantage of it.
But as a whole the perl community has got a hell of a lot more practice than the rails community at it - and of course rails has inherited the same fanboyish muppets that used to give perl a bad name (line noise? no, that's a phase you go through and grow out of if you're any good, takes about 3 months or however long it takes you to need to maintain your own line noise :), went on to give PHP a bad name, and in a few years will probably have given rails a bad name (possibly they are doing already? I dunno, being a perl head I tend to ignore that sort of groupthink idiocy, my language was unfashionable when I first learned it :)
I know numerous people who have started using Rails only recently and use plenty of gems and plugins (and even write/distribute their own in some cases).
There are muppets everywhere, but I don't think they dominate the Rails community.
Rails still looks hopelessly monolithic to a perl dev though - we can't quite see why you'd want to ship a DB library in core when, hey, web apps don't -all- talk to SQL databases.
As for the quality of said DB library, well, many smart ruby developers have torn it to pieces quite adequately so I'll just say "google is your friend" and not bother with a half-informed opinion of my own.
Take any worthwhile topic, and you'll find smart people on both sides of the fence. Many smart people bitch about ActiveRecord, but many more use it and find it highly productive. "Torn to pieces" my ass.
If you can't see why a web app framework might want to ship a DB library, you're blind.
I think it goes beyond basic dislike of the language...that would require knowledge of the language, which is pretty clearly lacking in many of the flames. I suspect it's often human tribal tendencies. Rubyists and Pythonistas see another tribe competing in the very same environment with very similar capabilities (because, let's face it, mild syntactic differences aside Perl, Python and Ruby are more alike than they are different when compared to almost any other language), and they also see an opportunity to combine to beat up on a currently larger and older tribe.
By the time you've spent enough time with a language to get past identifying with just that one tribe, you don't feel as aggressive an urge to pontificate on the suckage of other languages.
I think maybe you're categorizing me in group "d". ;-)
I've never said there aren't valid criticisms of Perl...just agreeing with msluyter's very astute meta-comment, and adding one more option. I believe that people exist in both groups "b" and "c"...I wasn't overloading method "b" to actually mean something else. Some people in "b" probably even have valid reasons for hating Perl...but, I think we can all agree that the majority of flames in any language thread come from a place of ignorance about the language. After all, if you really don't like a language, odds are good you don't do much work in it, and so don't actually know a lot about it.
But, if you think we need one more option, I won't argue. There probably are people in category "d" (in addition to me, it seems), as well.
Yup, I noticed the same thing. There are 110 comments between the two Perl articles today, and only 3 on the "government can take your laptop for no reason" article. Amusing.
I think people get really upset when they are told that Perl isn't actually dead. I mean, it is, right? How come people are still using it!? </sarcasm>
But why did Common Lisp need to build in at least 3 separate ways to map keys to values (getf, assoc, and hash tables)? The answer is because the language designers wanted all three.
Actually, the answer is that those three do different things. GETF is for property lists which look like '(key1 value1 key2 value2), ASSOC is for association lists which look like '((key1 . value1) (key2 . value2)), and GETHASH is for a hashtable which looks like a vector/array and not a list.
GETF returns the value of the first key that matches. GETHASH will return the value of the hashed key that matches.
ASSOC allows you to return any value for whatever key you're getting or whatever test you're using.
So each one has a different purpose. The trade-off is how you choose to map keys to values. It may be faster to use a hash-table instead of an assoc-list, or it may be easier to interact with an assoc-list rather than a property list. The point is that there's a choice and a reason why the choice is available.
This reminds me of all the newbie Java programmers who use the ArrayList class instead of looking for just the right data structure for what they want to do.
My complaint was having all of these in the core language. If I want to use property lists, why can't I just load the "plist" library? If I want association lists, why can't I just load the "alist" library? And so on... the core programming language is not the place to dump every algorithm ever created.
Once there was an idea in perl-land, that we should take 150 or so different little modules, package them together and make a Big Monolithic Release with Lots Of Stuff in it.
They thought they'd call it Perl on Poles.
Then we realised that big monolithic releases were a good idea in the same way as vista was a good idea, and went back to depending on the exact things we needed for our app, conveniently cut up so we could depend on lots of little libraries rather than one giant one that contained lots of stuff we never used.
I'm sorry you find a culture of software reuse an argument against a language. Here, let me sell you this dot net - fifty pee and a windows license.
He's not complaining about using modules. He's complaining about using one hundred and fifty modules, and you're attacking him on an argument he's not making.
Bugger. I was aiming for sarcastic hyperbole rather than trolling. Sorry.
I'm trying to attack the idea that using lots of small modules is worse than having a few big dependencies - CPAN dependency chains often -look- big because we try to break things down into the smallest unit of viable reuse. It's a bit more work but it's part of what makes CPAN so effective a toolkit.
If you want, re-read my post and try and mentally apply a deadpan english voice with more than a hint of sarcasm and see if that makes up for my poor phrasing.
That is explained in the next sentence after that.
You should really read the entire paragraph containing a point you want to reply to. If you just want bash Perl, reply to a point without a direct quote :P
* posts encoded in any character encoding, built-in to modern languages.
* supporting different rich text formats, equally available in modern languages.
* computing the MD5 sum of the post for the HTTP ETag header, built-in to modern languages.
* handing filesystem paths in a cross-platform manner, built-in to modern languages.
* parsing the configuration file, built-in to modern languages (for JSON, XML, YAML, KVP's or eval).
* reading PGP signatures, equally available in modern languages --- not that I'm sure why I'd want that in my blog.
Except for Textile or Markdown, I'm not sure there's anything here that would make me reach out of the box in Ruby or Python.
This all seems pedantic, I'm sure, but here's my point: CPAN is constantly cited as the killer feature for Perl, but:
(1) here's an article that makes that argument and doesn't show anything CPAN provides that you wouldn't get in a more modern language, and
(2) if you're wading through 200+ modules just to get a blog up, I'm seriously not sure that's an argument for how CPAN makes a developer's life easier. TMTOWTDI, yeah, but there's also value in making it clear and obvious what the right way is.
if we're going to do that, we get to rule out, say, lisp. Which I'd rather write over most "modern" languages any day.
And so far as I can tell, you're basically saying "I think the perl standard library should have more stuff in it and because it doesn't have the stuff -I- want in it, CPAN is pointless".
Well, sure. Except that not having all this stuff in core means I can update, say, my rich text processing stuff or a configuration parser on its own, and only re-QA that component rather than having to wait for an entire language point release.
And "wading" is a nicely loaded description as well. Here's what I did when I installed angerwhale:
tar xzf <tarball>
cd <unpacked dir>
perl Makefile.PL
make installdeps
and lo, from CPAN did the 50 or so modules that I didn't already have installed for something else that was -also- reusing that same code snap straight onto my system while I went for a coffee break.
perl is just syntax. CPAN is the language.
And by that standard all this -is- built in. It's just optional :)
"Modern language" --- you're right. I'm looking for a word that means "Python, Ruby, Scala, etc" but not Tcl and Perl. I'm fumbling trying to find it. Sorry.
The rest of your reply kind of misses my point. If the 50-or-so modules you get from CPAN have built-in analogues in Python, why do I care about CPAN? Can I get a raytracer straight out of CPAN? Sure. So? What's a profoundly useful library in CPAN that isn't easily matched in Python?
I bet you have an answer, and I'd like to hear it.
"Modern language" --- you're right. I'm looking for a word that means "Python, Ruby, Scala, etc" but not Tcl and Perl. I'm fumbling trying to find it. Sorry.
What modern features is Perl missing? I hate to break it to you, but Python and Ruby have basically the same featureset as Perl.
What's a profoundly useful library in CPAN that isn't easily matched in Python?
A single profoundly useful library is not the point of CPAN. It's finding that random library that you need in some corner of an obscure internal application where CPAN really shines. Every language has their super-great web framework. The depth and breadth of module available on the CPAN is Perl's strength.
If I had to pick a single CPAN module I couldn't be without, though, it would be Moose; followed closely by Catalyst and DBIx::Class.
"Modern language" --- I just agreed with you. And apologized.
Moose --- doesn't Moose just make Perl's metaclass programming as simple as Python and Ruby's already is?
Catalyst is an web MVC framework. DBIx::Class is an ORM. Clearly we can get those libraries elsewhere. Is there something really amazing in CPAN that I can't get in a gem in Ruby? I get that a lot of gems are crappy (Ruby's a younger community), so I'm not going to come back at you with some random -0.1alpha svn trunk thing.
The last time a django core dev looked at DBIx::Class in front of me the response was "shit, we need to steal that".
Sadly I didn't get to catch up with them properly at OSCON to find out if they'd manage to steal much of the awesome stuff yet.
SQLAlchemy probably already has similar features though, so maybe they don't need to.
Ruby can't handle MI. Ruby's metaprogramming seems limited. But I'm not informed. I've had several perl ->ruby guys come back to perl going "hey! it's like ruby but with a flexible object system" to me. But I don't know enough about it to have an opinion myself.
I think you'd have a hard time coming up with something that Ruby's metaprogramming can't handle where Perl's answer would be better than "eval". I could be wrong; I'm equally shady in Perl (I haven't written in it since 1996).
Ruby doesn't do multiple inheritance, though you really do get 90% of what reasonable people do with MI with mixins, which work beautifully.
To be honest, the best thing about CPAN isn't any specific module, it's the sheer breadth of them - and the ability to install everything in a uniform way and have it usually work. Plus things like the cpantesters and cpandeps system that make it fairly trivial to tell if something -will- work on all the platforms you're targeting before you commit yourself to it.
Of course, if you describe yourself as "an old PERL programmer" you may have missed a lot of the recent cool stuff on CPAN - the binary is called 'perl', the language 'Perl', and the mistake of calling it 'PERL' kinda went out with the 2001-era CGI.pm crowd (this isn't meant as an ad hominem - I've simply found that anybody who says 'PERL' as anything except a joke is -hugely- likely not to have taken advantage of most of CPAN and have no way of telling if you're an exception to that :)
I swear to god I'm not challenging you, I really want to know: what makes Moose more interesting than the metaclass programming you get ``for free'' with Python and Ruby?
The attribute metaprotocol and method modifiers are AFAIK rather more like the equivalents in CLOS or a smalltalk than they are like those in python/ruby, and the roles system is -way- nicer than mixins.
I actually considered once implementing mixins for perl the way ruby does them with an anon class to keep single inheritance, then abandoned the concept as being a colossal hack. python's MI OTOH is sane with a C3 MRO, so we stole that for perl - in the cases where a mixin or role isn't sufficient it works very nicely.
I'd suggest having a read of the Devel::REPL articles on http://chainsawblues.vox.com/ - that might show off the capabilities of roles+method modifiers better than I can explain.
Not sure if this helps you or relieves you of some concern but:
1) I doubt Angerwhale itself includes 200+ modules. The core Makefile lists about 62 modules. It's likely the number quoted was counting both the modules used by Angerwhale and the dependencies of those modules and so forth.
2) Current best practices for developing a Perl application say that you should build the application itself as a CPAN module, even if you don't plan to release on CPAN, since that way you can take advantage of all the work that's gone into CPAN testing and deployment tools. However, if you follow that best practice correctly, it will mean you will take great care to list all your dependencies and their minimum workable versions. You will do this even with a dependency that is part of a core Perl installation. For example, one of the dependencies listed in Angerwhale is 'File::Find', actually comes with a base install of Perl. You don't have to do anything for the application to work. However, for strong audit and good programming practice, you really should list what you application needs. That just makes it easier to install and to troubleshoot installation issues. Also, in the future it is likely that Perl core will be smaller, so that we can have the flexibility to target Perl more carefully to different needs (like say to people using Perl for system administration, versus those in a very constrained embedded market). So this is just a good practice to future proof your application.
3) The number of required modules is nothing to be afraid of. When you install a CPAN module, like by using the commandline 'cpan' application, it will automatically follow, download, run tests, and install, any required dependencies. All you really need to do is something like:
cpan Angerwhale
And the build tool do the rest for you. This is also a good way to develop your application, so that you can use Makefile as a build and a deployment tool. This is just part of the standard, best practices for Perl development.
All programming languages come with extended and standard libraries. To be efficient in any language requires that you learn to 'wade through' as you say, those libraries, their documentation and test examples. There is no doubt the CPAN model has some challenges. CPAN is widely distributed, varying in quality, and lives in the complex negotiation of needs and desires which is a hallmark of the Internet. Like the rest of the Internet it can be wildly anarchic and is often brutally merit based. There have definitely been times when I have cursed it. However I do believe it is a wonderful testament to the viability of open source, distributed development.
I don't get Markdown. Why make end-users learn a yet another markup language to make bold text or a table (unless all your users are news.yc readers, rather than the general public)?
Why not give them an actual bold text button? It's not hard.
Programming languages are just as much social/cultural constructs as spoken ones. The language's technical merits are just one factor. Sometimes, a bigger factor is the community which uses that language.
Choice of language makes a difference in productivity to your team, but in many cases, this will be swamped by other factors, like how experienced and knowledgeable they are and how well they work together.
Then again, there are highly specialized domains where a language will make you 100X more productive than another.
From a pragmatic point of view, if you need to "reinvent" stuff for some reasons, e.g to implement them in C or whatever, prototype it in perl as generic as possible and just translate it to C or your language of choice... look how they did it in perl (there's next to nothing they didn't implement by now), then implement the algorithm in "your" language. It saves you really lots of time.
Python has closures but has issues when changing variables within them. This leads most people to agree that Python's implementation of closures is insufficient.
See the following link for an example and more details:
Python's closures are basically read-only in the 2.x series. 3.0 will offer read-write access via the nonlocal keyword: http://www.python.org/dev/peps/pep-3104/
It still won't be exactly the same, because Perl uses `my $foo` once to declare its lexicals; Python will require `nonlocal foo` declarations in all scopes that will use `foo`. The final result is the same, though: using variables from outer scopes.
I think I agree with you: as benevolent programmers, we should pick the best tool for the job, without consideration for the platform, or the libraries. This would advance the art of software faster in the long run.
Unfortunately, we are forced to make decisions based on the ecosystem of our tools, because of short-term constraints.
But it irritates me when I need to get at gpg from a web application, and can't just use a "libgpg". I have to fork a gpg process, setup file descriptors just right, write input to a pipe, wait for input on another pipe, and then parse the result
It boggles the mind that a perl programmer, of all people, would think this. The relevant code for the above is generally something like:
or: The incredibly tight integration with external programs (e.g. the code to "setup file descriptors just right" consists of one byte!) is the very essence of what makes perl great and special. I'm just dumbfounded here. He likes perl but doesn't understand how to fork a process?I mean, the whole premise of the point is counter to the perl philosophy, which is that you're already on a great and useful platform and just need a tool to tie things together nicely. If you want a single platform designed around the idea that all meaningful tasks are available in a library without leaving the sandbox, you are looking at Java or .NET, certainly not perl...