Our future depends on bright, energetic, talented people who share a passion for creating the best product imaginable! We offer a challenging work environment, a competitive salary, and excellent benefits. Interested candidates should apply online using our contact form and selecting the "Human Resources" department. Please copy and paste your resume into the subject field.
The fact that they have no actual office, and use Mailboxes Etc as a mail drop, certainly makes the work environment challenging.
Another great line:
SEC Filings
You can browse SEC filings in Edgar by clicking here. Note that you will be redirected to an external website. We cannot guarantee the accuracy and timeliness of any information therein.
Collected Works of A.M. Turing
Morphogenesis
P.T. Saunders, Editor
Introduction
Turing's work in biology illustrated just as clearly as his other work his ability to identify a fundamental problem and to approach it in a highly original way, drawing remarkably little from what others had done. He chose to work on the problem of form at a time when the majority of biologists were primarily interested in other questions. There are very few references in these papers, and most of them are for confirmation of details rather than for ideas which he was following up. In biology, as in almost everything else he did within science -- or out of it -- Turing was not content to accept a framework set up by others.
Even the fact that the mathematics in these papers is different from what he used in his other work is significant. For while it is not uncommon for a newcomer to make an important contribution to a subject, this is usually because he brings to it techniques and ideas which he has been using in his previous field but which are not known in the new one. Now much of Turing's career up to this point had been concerned with computers, from the hypothetical Turing machine to the real life Colossus, and this might have been expected to have led him to see the development of an organism from egg to adult as being programmed in the genes and to set out to study the structure of the programs. This would also have been in the spirit of the times, because the combining of Darwinian natural selection and Mendelian genetics into the synthetic theory of evolution had only been completed about ten years earlier, and it was in the very next year that Crick and Watson discovered the structure of DNA. Alternatively, Turing's experience in computing might have suggested to him something like what are now called cellular automata, models in which the fate of a cell is determined by the states of its neighbours through some simple algorithm, in a way that is very reminiscent of the Turing machine.
For Turing, however, the fundamental problem of biology had always been to account for pattern and form, and the dramatic progress that was being made at that time in genetics did not alter his view. And because he believed that the solution was to be found in physics and chemistry it was to these subjects and the sort of mathematics that could be applied to them that he turned. In my view, he was right, but even someone who disagrees must be impressed by the way in which he went directly to what he saw as the most important problem and set out to attack it with the tools that he judged appropriate to the task, rather than those which were easiest to hand or which others were already using. What is more, he understood the full significance of the problem in a way that many biologists did not and still do not. We can see this in the joint manuscript with Wardlaw which is included in this volume, but it is clear just from the comment he made to Robin Gandy (Hodges 1983, p. 431) that his new ideas were "intended to defeat the argument from design".
This single remark sums up one of the most crucial issues in contemporary biology. The argument from design was originally put forward as a scientific proof of the existence of God. The best known statement of it is William Paley's (1802) famous metaphor of a watchmaker. If we see a stone on some waste ground we do not wonder about it. If, on the other hand, we were to find a watch, with all its many parts combining so beautifully to achieve its purpose of keeping accurate time, we would be bound to infer that it had been designed and constructed by an intelligent being. Similarly, so the argument runs, when we look at an organism, and above all at a human being, how can we not believe that there must be an intelligent Creator?
Turing was not, of course, trying to refute Paley; that has been done almost a century earlier by Charles Darwin. But the argument from design had survived, and was, and indeed remains, still a potent force in biolog
Re:Pac-Man alternates between 25% and 0% violence
on
The 64% Violent Pacman
·
· Score: 1
Sorry, I forgot the parens: "Take a (look and feel) free."
-Don
Pac-Man alternates between 25% and 0% violence
on
The 64% Violent Pacman
·
· Score: 3, Funny
Pac-Man's mouth is his only weapon, and it alternates between 25% open and 0% open, for an average of 12.5% open-mouthed violence.
SGI's been doing a pretty good job of sitting on OpenGL without making any improvements for years. What makes you think Microsoft can do a better job of stifling innovation than SGI's been doing?
Maybe SGI should make an accelerated sgiPOD that plays music faster than any other MP3 player on the market. Then you could listen to your whole music collection in a few minutes!
The only thing they still have of value is their wonderful 3D logo, designed by Scott Kim. Now THAT's worth something.
The Amsterdam Compiler Kit was originally known as the Free University Compiler Kit (or VUCK, since V stands for Free in Dutch). RMS wrote:
I would say that since the time about two and a half years ago when I actually started working on GNU, I've done more than half of the work. When I was getting ready to start working on the project, I first started looking around for what I could find already available free. I found out about an interesting portable compiler system which was called ``the free university compiler kit'', and I thought, with a name like that, perhaps I could have it. So, I sent a message to the person who had developed it asking if he would give it to the GNU project, and he said ``No, the university might be free, but the software they develop isn't'', but he then said that he wanted to have a UNIX compatible system too, and he wanted to write a sort of kernel for it, so why didn't I then write the utilities, and they could both be distributed with his proprietary compiler, to encourage people to buy that compiler. And I thought that this was despicable and so I told him that my first project would be a compiler.
I've just completed a large project using TurboGears, and I'm quite happy with it, considering how new it is (not even to version 1.0 yet).
The Kid templating system is wonderful and well designed: very Pythonic, XML centric, practical and easy to use. But it's pretty hard to trace and debug problems with templates, and it's not very smart about stripping out unnecessary white space (not a big deal, but the Kid compiler could be smarter about optimization, and inject extra information to make debugging easier).
So many other template systems attempt to fight against Python or XML, and end up with a big mess that tries to reinvent the wheel and ends up with something much worse than the sum of its parts. But Kid is straightforward and honest with Python and XML. You don't need to learn another weird half baked language.
I've done a lot of work with Zope and Plone, and I'm sick and tired of Zope's sloppy DTML, awkward TAL, inexplicable METAL, casterated "secure" python scripts, brittle SQL methods, insane acquisition, unidentified flying object models, and all of Plone's fractal complexity and self perpetuating bureaucracy, so Kid is a refreshing breath of fresh air.
I was already using SQLObject before I started using TurboGears (which was one reason I found it so easy to switch to TurboGears). I like it, and it works well for my current purposes, but I'm interested in learning more about SQLAlchemy, and maybe using it with more complex projects.
The project I just finished has about 12,000 lines of Python code, and it's quite template-heavy: about 300 templates, comprising more than 32,700 lines, almost a megabyte of XML Kid template source code. I consider the kid template content to be the crown jewels of the project, just as important as any of the Python source code, so it's all nicely indented and easy to read and maintain, like Python code. There's no place for sloppy templates, just as there's no place for sloppy code.
The idea that a templating system should't allow you to write any code is just as foolish as the idea that the templating system should invent a totally new programming language. I'm already quite happy with XML and Python, and have invested a lot in learning them and their associated tools, and I don't need to be protected from myself. Python and XML are both well designed and universally supported, so I have no need for a templating system that doesn't let me use the full power of Python, along with with the pure standard syntax of XML.
Re: Which was chosen?
Posted: Apr 21, 2006 6:46 AM
I'm using Django templates and am very happy with them. I've not had time to compare and contrast it to other frameworks, or even to try out other parts of Django. I do have to say that I am very happy with the way the Django project is being managed; they seem to really "get" open source community projects. I also like WSGI and Phillip Eby's wsgiref implementation, which has been made a part of Python 2.5.
I've decided not to officially endorse a particular web framework; it would be way too big a responsibility. I do recommend that web developers (I'm still not much of one) get together, share experiences, and ask the web framework developers to standardize low-level APIs in additionn to WSGI (PEP 333). Also, I recommend setting up a wiki page where web frameworks are compared and contrasted, as a service to prospective users.
So no, he doesn't prefer Django. It's official: he makes no endorsement whatsoever, except for the low level WSGI standard. He's using Django for at least one application, but he encourages people to compare and contrast all web frameworks.
How did you get from Guido's statement that "Django's gaining steam" to your statement that "Guido prefers Django"? Prefers it over what? Is that from your personal communication with him, something he said in public somewhere else, or are you reading something into that blog posting that I can't see? He doesn't mention anything about TurboGears or his preference in web frameworks, he simply states that Django is gaining steam in a big way. You're jumping to conclusions if you think that blog posting implies that he preferrs one web framework over another.
I'd be interested to know what Guido thinks of Zope, since he worked for Zope corporation in the past. And what he thinks of Zope Page Templates, since he worked on that code.
Oh yes, that horrible Democratic corruption which stains dresses, makes cigars smell like fish, and relieves the president's pent up tension after working all night to pass a budget after the god-fearing Republicans shut down the government. I forgot to mention that. Thanks for reminding me.
<sarcasm>I'm glad to know you Republican ass-holes are still fighting the good fight against consentual blow-jobs. Blow jobs kill a lot more people than senseless wars, and they cost taxpayers much more than $293,646,760,794. I'm glad you have your priorities straight, and that you aren't hipocrits for hold double standards.</sarcasm>
-Don
PS: <truth>Ann Coulter is a MAN, baby! And if you want to fuck her, then you're gay!<truth>
Back in the early Mac days, there was a naive Mac user whose computer crashed and put up a dialog with the bomb icon, saying "Sorry, a system error has occurred." So of course they jumped up from their seat and ran out of the room in terror, because they thought it meant the computer was about to explode!
So why stick with an inferior web hosting company? Python is already installed on most modern Linux systems, and it's free and easy to install on all Linux, Windows and Mac systems. If a web hosting company doesn't offer it, then they're hopelessly behind the time. If they refuse to install it, then their service sucks and they have no respect for their customers. If Python is missing and your provider refuses to install it, then it's only a symptom of much worse problems. What are you going to do when they refuse to install Perl or PHP modules you depend on, or upgrade Perl and PHP and fix security holes as soon as they're reported?
Why make the wrong decision about programming languages, just because you made the wrong decision about hosting providers? If your provider doesn't support Python, or install it when you ask, then you should dump them, because they don't deserve to stay in business. There is no shortage of quality web hosting providers who support Python and other scripting languages that are better than Perl and PHP.
Would you send your kids to an elementary school that taught Intelligent Design, but didn't support Evolution? Are you resigned to raising your children to be superstitious idiots because their parochial school refuses to change their ignorant ways, or would you switch them to another better school?
As you said, the things that Perl programmers love about the language make other programmers hate it. But that's peculuar to Perl, which is one of the only languages that goes out of its way to be hard to program, hard to read, hard to learn, and hard to understand, on purpose.
PHP is simply ignorant, not designed badly on purpose. When people who understand programming language design point out PHP's faults to its designers (who obviously don't understand programming language design, because if they did, they wouldn't have made all those mistakes in the first place), at least they attempt to correct the problems in the next version of PHP, to the dismay of all the programmers whose PHP programs depended on that badly designed behavior. That's why each version of PHP breaks programs written for the previous version.
But on the other hand, Perl is absolutely maliscious, and designed badly on purpose. When people who understand programming language design point out Perl's faults to its designers (who should have known better), they get defensive, go out of their way to rationalize their problems, strike back by putting even more badly designed features and pointlessly complex syntax into the language, slapping on band-aids, paper machette, and self-adhesive Michael-Jackson-Noses to cover up the problems, and then they pretend like all those hacks and kludges are actually good ideas, which make Perl more enjoyable to their tastes.
Python and Ruby are designed the opposite way as Perl, by people who actually understand programming language design. They have low syntactic surface area and simple semantics on purpose, so they're easy to learn, easy to read, easy to understand, easy to use, easy to maintain, and even nice to look at!
Programming in PHP is like building a house out of straw. But programming in Perl is like building with Lead and Asbestos. There's no excuse for not knowing about the dangers, and anyone who denies that Perl has many fundamental problems is a liar. It's simply irresponsible, and whoever does it professionally deserves to have their ass sued off for being so incompetent to expose their employer and users to such hazards.
When somebody announces they're using an ignorant language like PHP, and wants to mix it with a dangerous language like Perl, the right thing to do is to warn them that both langauges they're using are bad, for different reasons, and offer some better alternatives. Turing completeness does not mean that all programming languages are the same. Programming language design is user interface design, because programmers are language users. And there is no excuse for using a bad user interface, when so many better ones are available. Like drunk drivers talking on cell phones, Perl advocates need to be pulled over, taken off the road, and reformed, to stop them from causing more horrible accidents, and recruiting others to repeat their dangerous behavior.
Good languages are hard to design. Scriptable applications that dream up their own special-purpose scripting languages tend to have a lot of deep flaws and fundamental limitations. Most of the developer's resources go into the main application, not designing and supporting the scripting language. And special purposes non-standard languages usually don't have good development and debugging tools, either.
Python is a very well designed language, with a huge active community and robust collection of tools and extension modules, which was designed to be used as a general purpose application scripting language, from day one. Its syntax is quite simple, and there aren't a lot of exceptions to the rules (like Perl) or subtle nuances and inexplicable quirks (like PHP), so it's quite easy to learn.
One of the big upsides to using Python as an application scripting language is that all of the standard and add-on Python modules are at your disposal, and if you need to do anything specialized, you can write your own Python modules (using SWIG makes that quite easy).
Why would you want to plug your own custom Python modules into a scripable application like Maya? You might want to call libraries that import and export content, and integrate existing i/o and previewing code from the applications that consume the content you're building in Maya. And if your other applications are also scripted in Python, then you can use the same code and modules in your application and your tools, which really rocks! Python on Windows also has full support for OLE Automation, so you can easily integrate applications like Excel, and ActiveX controls, too.
But to stay on topic:
Despite its crystal-meth-like popularity, PHP is an ameteurishly designed language, and has a long track record of each new version breaking compatibility by attempting to paper-machete over stupid mistakes of the past, that shouldn't have been made in the first place. But the difference between PHP and Perl, is that PHP is just naive, and didn't know it was making those mistakes. But Perl is totally malevolent, it chose to make all those mistakes on purpose, and it revels in its own fractal complexity.
Sure, go ahead with your experiment to arrange a shotgun marriage of PHP and Perl. But beware: this could happen to you!
You'd probably be a LOT better off it you used Python and the Python Imaging Library, instead of trying to noodle around with combining PHP/Perl/ImageMagick.
First of all, PIL can solve your imaging problem, but more importantly, Python can solve your PHP problem. And then you won't have to get yourself hooked on a Perl problem as well.
There is of course an ImageMagick module for Python. But I prefer to use PIL, which is full featured, well integrated with Python, robust and efficient, and plays nicely will with Numerical Python.
Well you could use the PHthon PHP/Python bridge, then the Perlthon Python/Perl bridge.
...But what's the point of writing everything in one file but different languages?
Why not write a pure PHP script that calls a pure Perl script directly?
Or are you just looking for a way to avoid using more than one file, by making your application much more complex? Are they paying you by the hour, instead of for results, efficiency, simplicity, robustness, etc?
Wasn't Parrot supposed to solve all these problems? Or was that just a sick joke that some misguided people too much too seriously?
You might want to consider writing a back-end for SWIG to support your language, which will make it easy to plug in new primitives and integrate libraries with your language. That will sure save you a lot of work, and enable developers to easily plug their own stuff in! SWIG lets you write interface definition wrappers for libraries (and can even use C++ header files directly, or you can tailor the interface by simplifying and modifying them with annotations), and SWIG automatically generates all the glue code for a wide range of languages, or pure xml that describes the interfaces for other tools to grok. There's an API for extending SWIG and writing new back-ends.
SWIG is brilliantly and practically designed, and deals well with harsh realities and nuances of C++. It totally rocks!
For a great example of a complex library exposed to scripting languages via SWIG, check out the Intel Open Source Computer Vision Library, which plugs into many scripting languages by describing its APIs to SWIG. If you wrote your own language back-end, you'd be able to SWIGify an OpenCV interface to your own language, as well as any other library that has a SWIG interface.
Slashdot Mirror
Anybody with a really short resume looking for a job at Phantom?
http://www.phantom.net/content/contactUs/careers.h tml:
The fact that they have no actual office, and use Mailboxes Etc as a mail drop, certainly makes the work environment challenging. Another great line:
Why does Phantom have a disclaimer warning investors not to trust what they read about them on the SEC site? It should be reworded: "Phantom cannot guarantee the accuracy and timeliness of any information we file with the SEC", like: Notification of inability to timely file Form 10-Q or 10-QSB, or [Amend]Statement of changes in beneficial ownership of securities, or Registration Withdrawal Request.
-Don
And then there's things we said we knew, that we knew we didn't know.
-Don
I wrote The Sims 1 Crowd Sitter to simulate the effects of Bush's (lack of) response to Hurricaine Katrina.
-Don
Robot Odyssey is one of the all-time high-brow games, which is essentially a visual programming language (for robots), with encapsulation (chips)!
-Don
Collected Works of A.M. Turing
Morphogenesis
P.T. Saunders, Editor
Introduction
Turing's work in biology illustrated just as clearly as his other work his ability to identify a fundamental problem and to approach it in a highly original way, drawing remarkably little from what others had done. He chose to work on the problem of form at a time when the majority of biologists were primarily interested in other questions. There are very few references in these papers, and most of them are for confirmation of details rather than for ideas which he was following up. In biology, as in almost everything else he did within science -- or out of it -- Turing was not content to accept a framework set up by others.
Even the fact that the mathematics in these papers is different from what he used in his other work is significant. For while it is not uncommon for a newcomer to make an important contribution to a subject, this is usually because he brings to it techniques and ideas which he has been using in his previous field but which are not known in the new one. Now much of Turing's career up to this point had been concerned with computers, from the hypothetical Turing machine to the real life Colossus, and this might have been expected to have led him to see the development of an organism from egg to adult as being programmed in the genes and to set out to study the structure of the programs. This would also have been in the spirit of the times, because the combining of Darwinian natural selection and Mendelian genetics into the synthetic theory of evolution had only been completed about ten years earlier, and it was in the very next year that Crick and Watson discovered the structure of DNA. Alternatively, Turing's experience in computing might have suggested to him something like what are now called cellular automata, models in which the fate of a cell is determined by the states of its neighbours through some simple algorithm, in a way that is very reminiscent of the Turing machine.
For Turing, however, the fundamental problem of biology had always been to account for pattern and form, and the dramatic progress that was being made at that time in genetics did not alter his view. And because he believed that the solution was to be found in physics and chemistry it was to these subjects and the sort of mathematics that could be applied to them that he turned. In my view, he was right, but even someone who disagrees must be impressed by the way in which he went directly to what he saw as the most important problem and set out to attack it with the tools that he judged appropriate to the task, rather than those which were easiest to hand or which others were already using. What is more, he understood the full significance of the problem in a way that many biologists did not and still do not. We can see this in the joint manuscript with Wardlaw which is included in this volume, but it is clear just from the comment he made to Robin Gandy (Hodges 1983, p. 431) that his new ideas were "intended to defeat the argument from design".
This single remark sums up one of the most crucial issues in contemporary biology. The argument from design was originally put forward as a scientific proof of the existence of God. The best known statement of it is William Paley's (1802) famous metaphor of a watchmaker. If we see a stone on some waste ground we do not wonder about it. If, on the other hand, we were to find a watch, with all its many parts combining so beautifully to achieve its purpose of keeping accurate time, we would be bound to infer that it had been designed and constructed by an intelligent being. Similarly, so the argument runs, when we look at an organism, and above all at a human being, how can we not believe that there must be an intelligent Creator?
Turing was not, of course, trying to refute Paley; that has been done almost a century earlier by Charles Darwin. But the argument from design had survived, and was, and indeed remains, still a potent force in biolog
Sorry, I forgot the parens: "Take a (look and feel) free."
-Don
Pac-Man's mouth is his only weapon, and it alternates between 25% open and 0% open, for an average of 12.5% open-mouthed violence.
-Don
Sun has a long track record of making promises they couldn't keep.
That's why Sun had to rename Project DOE (Distributed Objects Everywhere) to Project DOPE (Distributed Objects Practically Everywhere)!
-Don
SGI's been doing a pretty good job of sitting on OpenGL without making any improvements for years. What makes you think Microsoft can do a better job of stifling innovation than SGI's been doing?
-Don
Maybe SGI should make an accelerated sgiPOD that plays music faster than any other MP3 player on the market. Then you could listen to your whole music collection in a few minutes!
The only thing they still have of value is their wonderful 3D logo, designed by Scott Kim. Now THAT's worth something.
-Don
The Amsterdam Compiler Kit was originally known as the Free University Compiler Kit (or VUCK, since V stands for Free in Dutch). RMS wrote:
-Don
I've just completed a large project using TurboGears, and I'm quite happy with it, considering how new it is (not even to version 1.0 yet).
The Kid templating system is wonderful and well designed: very Pythonic, XML centric, practical and easy to use. But it's pretty hard to trace and debug problems with templates, and it's not very smart about stripping out unnecessary white space (not a big deal, but the Kid compiler could be smarter about optimization, and inject extra information to make debugging easier).
So many other template systems attempt to fight against Python or XML, and end up with a big mess that tries to reinvent the wheel and ends up with something much worse than the sum of its parts. But Kid is straightforward and honest with Python and XML. You don't need to learn another weird half baked language.
I've done a lot of work with Zope and Plone, and I'm sick and tired of Zope's sloppy DTML, awkward TAL, inexplicable METAL, casterated "secure" python scripts, brittle SQL methods, insane acquisition, unidentified flying object models, and all of Plone's fractal complexity and self perpetuating bureaucracy, so Kid is a refreshing breath of fresh air.
I was already using SQLObject before I started using TurboGears (which was one reason I found it so easy to switch to TurboGears). I like it, and it works well for my current purposes, but I'm interested in learning more about SQLAlchemy, and maybe using it with more complex projects.
The project I just finished has about 12,000 lines of Python code, and it's quite template-heavy: about 300 templates, comprising more than 32,700 lines, almost a megabyte of XML Kid template source code. I consider the kid template content to be the crown jewels of the project, just as important as any of the Python source code, so it's all nicely indented and easy to read and maintain, like Python code. There's no place for sloppy templates, just as there's no place for sloppy code.
The idea that a templating system should't allow you to write any code is just as foolish as the idea that the templating system should invent a totally new programming language. I'm already quite happy with XML and Python, and have invested a lot in learning them and their associated tools, and I don't need to be protected from myself. Python and XML are both well designed and universally supported, so I have no need for a templating system that doesn't let me use the full power of Python, along with with the pure standard syntax of XML.
-Don
Guide van Rossum writes :
So no, he doesn't prefer Django. It's official: he makes no endorsement whatsoever, except for the low level WSGI standard. He's using Django for at least one application, but he encourages people to compare and contrast all web frameworks.
-Don
How did you get from Guido's statement that "Django's gaining steam" to your statement that "Guido prefers Django"? Prefers it over what? Is that from your personal communication with him, something he said in public somewhere else, or are you reading something into that blog posting that I can't see? He doesn't mention anything about TurboGears or his preference in web frameworks, he simply states that Django is gaining steam in a big way. You're jumping to conclusions if you think that blog posting implies that he preferrs one web framework over another.
I'd be interested to know what Guido thinks of Zope, since he worked for Zope corporation in the past. And what he thinks of Zope Page Templates, since he worked on that code.
-Don
Oh yes, that horrible Democratic corruption which stains dresses, makes cigars smell like fish, and relieves the president's pent up tension after working all night to pass a budget after the god-fearing Republicans shut down the government. I forgot to mention that. Thanks for reminding me.
I Miss Monica - Ode to an intern.
<sarcasm>I'm glad to know you Republican ass-holes are still fighting the good fight against consentual blow-jobs. Blow jobs kill a lot more people than senseless wars, and they cost taxpayers much more than $293,646,760,794. I'm glad you have your priorities straight, and that you aren't hipocrits for hold double standards.</sarcasm>
-Don
PS: <truth>Ann Coulter is a MAN, baby! And if you want to fuck her, then you're gay!<truth>
Dear God, for the sake of humanity, please take the rest of those corrupt Republican potato chips!
-Don
Back in the early Mac days, there was a naive Mac user whose computer crashed and put up a dialog with the bomb icon, saying "Sorry, a system error has occurred." So of course they jumped up from their seat and ran out of the room in terror, because they thought it meant the computer was about to explode!
-Don
So why stick with an inferior web hosting company? Python is already installed on most modern Linux systems, and it's free and easy to install on all Linux, Windows and Mac systems. If a web hosting company doesn't offer it, then they're hopelessly behind the time. If they refuse to install it, then their service sucks and they have no respect for their customers. If Python is missing and your provider refuses to install it, then it's only a symptom of much worse problems. What are you going to do when they refuse to install Perl or PHP modules you depend on, or upgrade Perl and PHP and fix security holes as soon as they're reported?
Why make the wrong decision about programming languages, just because you made the wrong decision about hosting providers? If your provider doesn't support Python, or install it when you ask, then you should dump them, because they don't deserve to stay in business. There is no shortage of quality web hosting providers who support Python and other scripting languages that are better than Perl and PHP.
Would you send your kids to an elementary school that taught Intelligent Design, but didn't support Evolution? Are you resigned to raising your children to be superstitious idiots because their parochial school refuses to change their ignorant ways, or would you switch them to another better school?
-Don
As you said, the things that Perl programmers love about the language make other programmers hate it. But that's peculuar to Perl, which is one of the only languages that goes out of its way to be hard to program, hard to read, hard to learn, and hard to understand, on purpose.
PHP is simply ignorant, not designed badly on purpose. When people who understand programming language design point out PHP's faults to its designers (who obviously don't understand programming language design, because if they did, they wouldn't have made all those mistakes in the first place), at least they attempt to correct the problems in the next version of PHP, to the dismay of all the programmers whose PHP programs depended on that badly designed behavior. That's why each version of PHP breaks programs written for the previous version.
But on the other hand, Perl is absolutely maliscious, and designed badly on purpose. When people who understand programming language design point out Perl's faults to its designers (who should have known better), they get defensive, go out of their way to rationalize their problems, strike back by putting even more badly designed features and pointlessly complex syntax into the language, slapping on band-aids, paper machette, and self-adhesive Michael-Jackson-Noses to cover up the problems, and then they pretend like all those hacks and kludges are actually good ideas, which make Perl more enjoyable to their tastes.
Python and Ruby are designed the opposite way as Perl, by people who actually understand programming language design. They have low syntactic surface area and simple semantics on purpose, so they're easy to learn, easy to read, easy to understand, easy to use, easy to maintain, and even nice to look at!
Programming in PHP is like building a house out of straw. But programming in Perl is like building with Lead and Asbestos. There's no excuse for not knowing about the dangers, and anyone who denies that Perl has many fundamental problems is a liar. It's simply irresponsible, and whoever does it professionally deserves to have their ass sued off for being so incompetent to expose their employer and users to such hazards.
When somebody announces they're using an ignorant language like PHP, and wants to mix it with a dangerous language like Perl, the right thing to do is to warn them that both langauges they're using are bad, for different reasons, and offer some better alternatives. Turing completeness does not mean that all programming languages are the same. Programming language design is user interface design, because programmers are language users. And there is no excuse for using a bad user interface, when so many better ones are available. Like drunk drivers talking on cell phones, Perl advocates need to be pulled over, taken off the road, and reformed, to stop them from causing more horrible accidents, and recruiting others to repeat their dangerous behavior.
-Don
Good languages are hard to design. Scriptable applications that dream up their own special-purpose scripting languages tend to have a lot of deep flaws and fundamental limitations. Most of the developer's resources go into the main application, not designing and supporting the scripting language. And special purposes non-standard languages usually don't have good development and debugging tools, either.
Python is a very well designed language, with a huge active community and robust collection of tools and extension modules, which was designed to be used as a general purpose application scripting language, from day one. Its syntax is quite simple, and there aren't a lot of exceptions to the rules (like Perl) or subtle nuances and inexplicable quirks (like PHP), so it's quite easy to learn.
One of the big upsides to using Python as an application scripting language is that all of the standard and add-on Python modules are at your disposal, and if you need to do anything specialized, you can write your own Python modules (using SWIG makes that quite easy).
Why would you want to plug your own custom Python modules into a scripable application like Maya? You might want to call libraries that import and export content, and integrate existing i/o and previewing code from the applications that consume the content you're building in Maya. And if your other applications are also scripted in Python, then you can use the same code and modules in your application and your tools, which really rocks! Python on Windows also has full support for OLE Automation, so you can easily integrate applications like Excel, and ActiveX controls, too.
But to stay on topic: Despite its crystal-meth-like popularity, PHP is an ameteurishly designed language, and has a long track record of each new version breaking compatibility by attempting to paper-machete over stupid mistakes of the past, that shouldn't have been made in the first place. But the difference between PHP and Perl, is that PHP is just naive, and didn't know it was making those mistakes. But Perl is totally malevolent, it chose to make all those mistakes on purpose, and it revels in its own fractal complexity.
Sure, go ahead with your experiment to arrange a shotgun marriage of PHP and Perl. But beware: this could happen to you!
-Don
You'd probably be a LOT better off it you used Python and the Python Imaging Library, instead of trying to noodle around with combining PHP/Perl/ImageMagick.
First of all, PIL can solve your imaging problem, but more importantly, Python can solve your PHP problem. And then you won't have to get yourself hooked on a Perl problem as well.
There is of course an ImageMagick module for Python. But I prefer to use PIL, which is full featured, well integrated with Python, robust and efficient, and plays nicely will with Numerical Python.
-Don
Thanks a lot, slashdot subject line filter. Those equal signs were suppost to be => arrows -- I didn't mean that they were equal (or ordered).
-Don
Well you could use the PHthon PHP/Python bridge, then the Perlthon Python/Perl bridge.
Wasn't Parrot supposed to solve all these problems? Or was that just a sick joke that some misguided people too much too seriously?
-Don
You might want to consider writing a back-end for SWIG to support your language, which will make it easy to plug in new primitives and integrate libraries with your language. That will sure save you a lot of work, and enable developers to easily plug their own stuff in! SWIG lets you write interface definition wrappers for libraries (and can even use C++ header files directly, or you can tailor the interface by simplifying and modifying them with annotations), and SWIG automatically generates all the glue code for a wide range of languages, or pure xml that describes the interfaces for other tools to grok. There's an API for extending SWIG and writing new back-ends.
SWIG is brilliantly and practically designed, and deals well with harsh realities and nuances of C++. It totally rocks!
For a great example of a complex library exposed to scripting languages via SWIG, check out the Intel Open Source Computer Vision Library, which plugs into many scripting languages by describing its APIs to SWIG. If you wrote your own language back-end, you'd be able to SWIGify an OpenCV interface to your own language, as well as any other library that has a SWIG interface.
-Don
You like simple API's for solving complex problems? Then you must LOVE ioctl()!
-Don