Are you trying to deny that other languages like Python and Ruby are flexible, extensible and easy to use? In fact, they're much more flexible, extensible and easier to use than PHP, by a long shot.
There's nothing special about PHP that doesn't apply to other languages, and you can't deny that PHP is severely flawed in its own peculiar ways.
I'm not judging PHP by rumor, nor trying to compare it to other languages I don't know. Anyone with enough perspective to compare PHP with other languages can understand and admit to PHP's limitations. Why can't you? Is PHP the first and only language you ever learned? If you had anything decent to compare it with, you would realize how bad PHP sucks in comparison to the alternatives.
Another point about your buggy image resizer web page: Your disclaimer is a lie!
We do not store, copy or use the images processed through this site by any means - your image is piped from the '$_POST' variable directly to a function that processes and outputs it to download.
Then how do you explain this error message:
Warning: imagecreatefromgif(): '/tmp/phpu5sGOq' is not a valid GIF file in/home/imageuti/public_html/index.php on line 125
Is it just my impression, or are most PHP apologists really as incompetent as you?
By the way, your amazing image resizer web service that you advertise in your link has some wee bugs. Wow, that's some really amazing powerful PHP code you wrote there, which really demonstrates your mastery of PHP, and shows how much better PHP is than any other language. There's no way anyone could have done that in any language besides PHP, because PHP is just so powerful and easy to use, when it comes to resizing images. You must have to pay a lot in web hosting fees to run such a sophisticated web service. Have you already received thousands of dollars in PayPal donations from your amazing service, or sold your great online image resizing idea to Kleiner Perkins as the next big Web 2.0 startup company?
Warning: Division by zero in/home/imageuti/public_html/index.php on line 108
Warning: imagecreatetruecolor(): Invalid image dimensions in/home/imageuti/public_html/index.php on line 122
Warning: imagecreatefromgif(): '/tmp/phpu5sGOq' is not a valid GIF file in/home/imageuti/public_html/index.php on line 125
Warning: imagecopyresized(): supplied argument is not a valid Image resource in/home/imageuti/public_html/index.php on line 129
Warning: Cannot modify header information - headers already sent by (output started at/home/imageuti/public_html/index.php:108) in/home/imageuti/public_html/index.php on line 132
Warning: Cannot modify header information - headers already sent by (output started at/home/imageuti/public_html/index.php:108) in/home/imageuti/public_html/index.php on line 133
Warning: imagejpeg(): supplied argument is not a valid Image resource in/home/imageuti/public_html/index.php on line 135
It is easy to understand that how any post saying anything against java gets moderated down like hell.
Ahem -- REALITY CHECK: YOUR stupid PHP-fanboy post was moderated -1 Troll, and the pro-Java, pro-Apache post was moderated +1 Interesting.
Please explain why you think -1 > 1? Is there some quirk in PHP's numeric handling, type conversion, identity and comparison operators that has you confused about the order of integers?
You're the worst kind of PHP apologist, with your reality-denying Rumsfeldian arguments. The whole point of this discussion is the PHP developer's stubborn refusal to address security issues, and their consistent mis-behavior of sweeping problems under the rug and refusing to fix bugs. The fact that PHP is widely used makes it EVEN MORE IMPORTANT to fix its bugs and design flaws. But as your twisted argument goes, PHP's popularity is an EXCUSE for having so many bugs and design flaws. Blame the media for the casualties in Iraq, why don't you?
Nobody's arguing about whether or not PHP is buggy and badly designed. That's simply an undisputed fact. But you're trying to claim its outrageous number of bugs and design flaws is OK because PHP is widely used, and that's totally ridiculous, and outright negligent.
Absolutely right. The effort required to "fix" PHP is gargantuan (and futile) compared to the effort of simply learning a better language that doesn't need to be "fixed". It's ridiculous to put any more effort into PHP, when so many excellent alternatives are immediately available.
Monolinguistic newbie PHP apologists: There is nothing "special" about PHP. The feeling of power it gives you is from the COMPUTER, not the language. Every other programming language gives you the EXACT same feeling of power. PHP is not any easier to learn than most other modern languages, in fact it's much harder to learn to deal with all of its nuances, quirks, bugs, limitations, and work around all of its design flaws, which you don't have to worry about with better languages like Ruby and Python, which are both extremely easy to learn and use. PHP's simplicity is an ILLUSION, and its flaws are a FACT.
Case in point: Ruby's ActiveRecord and Python's SQLAlchemy make it MUCH EASIER and also MUCH SAFER to access SQL databases, than anything PHP has. And that's not because nobody's bothered to write a decent ORM in PHP: they have, and they failed miserably. If you think you can do a better job than Zend's ZActiveRecord Boondoggle, then go ahead and try, but even the charlitans who DESIGNED PHP were so overconfident in its abilities and broadsided by its limitations and design flaws that they didn't even understand themselves before they tried and failed.
Wrong: PHP, Perl and Python and Java are all written in C, not C++. Do you know ANY other language than PHP? If not, you're just ignorant: why do you think your opinion matters?
You're also wrong that PHP rules on "website/browser-server". First of all, nobody runs PHP in the browser. Second of all, PHP doesn't rule on the server: it totally sucks compared to the alternatives.
Compare PHP to other languages like Python, Perl, Java and Ruby: it's much worse, buggier, and poorly designed compared to all the alternatives.
If you really think PHP doesn't suck, then please explain which database interface you use in PHP, and how it compares to SQLAlchemy and ActiveRecord in terms of power, security, flexability, ease of use, and performance. That's my point: PHP totally sucks in comparison to the alternatives, and its majorly fucked up design flaws and broken object model make it impossible to do anything in PHP like the popular and powerful ActiveRecord and SQLAlchemy do.
While you're at it, please explain why you believe that PHP's object model is not totally fucked up, and justify its bugs and limitations with respect static methods as I described above, explain why the PHP team refuses to fix those design flaws, and demonstrate how you'd work around those flaws to write an ActiveRecord-like ORM, the way Zend attempted to do but miserably failed. Maybe you can teach the charlitans at Zend a thing or two, if you're such a hot PHP expert.
PHP can't force to to write good code, but it certainly forces you to write bad code.
Case in point: Zend's ZActiveRecord Boondoggle. PHP's object model is so broken that it can't support an ORM as simple and easy to use as Ruby's ActiveRecord, let alone one as powerful and flexible as Python's SQLAlchemy.
How do PHP's "numerous other data abstraction layers" compare to ActiveRecord and SQLAlchemy? Why can't Zend themself figure out how to implement their own version of ActiveRecord? It's because a fatal flaw in the design of the PHP language, that's why.
It's no wonder so many people are abandoning PHP for better languages like Ruby and Python.
It is not the case, however, that the PHP project is trying to conceal the fact that PHP has been implemented in a very unsafe way.
Parse that carefully. It says the PHP project is not trying to conceal the fact. What fact? The fact that PHP has been implemented in a very unsafe way.
Oh, that fact. Yes, it's a pesky little fact, indeed. But the fact that they're arguing about whether or not they're trying to conceal it, instead of arguing about how to best address that inconvenient little truth, is a big problem.
PHP's implementation is unsafe, fundamentally flawed, insecure, and it's badly designed to its very core. That's a fact. Any apologist who counters "but it gets the job done" is ignorant of PHP's problems, and ignoring the fact that there are many other open source languages out there that are much better designed, also get the job done, are at least as easy to learn and use as PHP, without all the bugs and security holes, and with many important advantages.
There's no reason to be using PHP to write new software, except ignorance of other languages and refusal to learn.
The effect he has on the success rate of attacks pales in comparison to the effect the PHP's long track record of horrible bugs and design flaws has on the success rate of attacks. Blame the people who wrote the bugs and mis-designed all the security holes and language mis-features, not the people who want to fix them.
If he raises people's awareness enough that some people STOP USING PHP, then he will have had a positive effect.
As long as we were pulling numbers out of our asses:
That $10-$20k increase doesn't nearly make up for the $40k decrease because you're dumb enough to use a horrible language like PHP.
If I didn't use and program in php, then I wouldn't know first hand what was so horrible about it.
You're not qualified to complain about a language (or anything else) if you don't know what's wrong with it from first hand experience.
Back to the discussion: So which database interface do you use in PHP, and how is it better and more secure than SQLAlchemy or ActiveRecord?
[I posted this earlier in the context of PostgreSQL Slammed by PHP Creator, but it bears repeating, since the charlitans at Zend still haven't addressed the problem, and NEVER WILL. Would anyone from Zend please finally comment, and explain just how PHP's plan for a database solution is better and more secure than Python's SQLAlchemy? -Don]
The creators of PHP are morons, and their support company Zend is dishonest and incompetent. The ZActiveRecord boondoggle demonstrates exactly what I mean: They can't program their way out of a paper bag, an don't even understand the limitations of the very language that they haphazardly "designed".
It makes me laugh that Lerdorf would slam Postgres, because the PHP designers have no understanding of object oriented programming or databases: instead they invent half baked cargo-cult designs, which are naive reactions to other systems they don't understand: they try to ape their surface features without understanding the reasons behind the way they're designed.
PHP references were thrown in as a band-aid to work around the horrible design flaw that arrays and objects were foolishly DEEP COPIED by default. If you pass or return an array from function to function, its contents are DEEP COPIED, which is EXTREMELY inefficient and leads to all kinds of horrible bugs because it's the last thing a sane programmer would expect. So instead of fixing the design flaw in PHP, they add "references" that LOOK and SOUND like C++ references, but actually are completely different, again misleading programmers into thinking they understand what's going on, but working totally differently than a sane person would expect. PHP references are actually half baked symbol table references. ThesloppyimplementationcausedmanybugsthatCOREDUMPPHP! PHP references were so poorly thought out and badly designed, that there were many edge conditions that they hadn't considered, that simply didn't work together, caused memory leaks and core dumps, and had useless and confusing semantics: callers passing references, functions declaring that they take references, functions returning references, etc. Compare that to C++'s simple and consistent definition of references in term of pointers. The only way to make a PHP reference to an object is to put it in a variable -- you can't make a reference to a field of an object or the return value of a function without storing it in a temporary variable -- totally unlike C++, and totally stupid.
PHP's object oriented programming system is a half-baked imitation of C++'s object model, haphazardly designed by charlitans who had no clue about the fundamentals of object oriented programming, elegant language design or efficient implementation. First of all, if you're going to try to imitate an existing design without understanding it, then for god's sake, at least imitate a language whose object system doesn't suck, and a language that has similar semantics to the language you're trying to kludge. C++ is a static compiled language, and its object system deeply reflects that fact. (That is to say, there's very little reflection beyond RTTI, because the compiler throws all the interesting stuff away! And C++'s oop design had to make many horrible compromises because the C++ object system was designed to map directly into C se
Since you're wise enough to dump PHP and switch to Python, and you're looking for a good way to do SQL, then you should definitely check out SQLAlchema. It's light years ahead of Ruby's "ActiveRecord", plus it has several different front-ends that simplify it and make it as easy to use as Ruby's ActiveRecord and Python's SQLObject, while still allowing you to use its much more advanced features.
Not only is it much more powerful than Ruby's ActiveRecord (which is causing people to abandon PHP in droves), but SQLAlchemy is astronomically better than anything PHP has, and PHP will never have anything that even approaches ActiveRecord because of foolish bugs and design flaws that the charlitans on the PHP team stubbornly refuse to fix. (As described in detail in Zend's ZActiveRecord Boondoggle.)
SQLAlchemy is the Python SQL toolkit and Object Relational Mapper that gives application developers the full power and flexibility of SQL.
It provides a full suite of well known enterprise-level persistence patterns, designed for efficient and high-performing database access, adapted into a simple and Pythonic domain language.
SQLALCHEMY'S PHILOSOPHY
SQL databases behave less and less like object collections the more size and performance start to matter; object collections behave less and less like tables and rows the more abstraction starts to matter. SQLAlchemy aims to accommodate both of these principles.
SQLAlchemy doesn't view databases as just collections of tables; it sees them as relational algebra engines. Its object relational mapper enables classes to be mapped against the database in more than one way. SQL constructs don't just select from just tables--you can also select from joins, subqueries, and unions. Thus database relationships and domain object models can be cleanly decoupled from the beginning, allowing both sides to develop to their full potential.
Scales Up
Powerful enough for complicated tasks, such as:
* Eager-load a graph of objects and their dependencies via joins
* Map recursive adjacency structures automatically
* Map objects to not just tables but to any arbitrary join or select statement
* Combine multiple tables together to load whole sets of otherwise unrelated objects from a single result set
* Commit entire graphs of object changes in one step
Scales Down
Extremely easy to use for all the basic tasks, such as:
* Constructing SQL from Python expressions
* Pooling database connections
* Loading objects from the database and saving changes back
DBA Approved
Built to conform to what DBAs demand, including the ability to swap out generated SQL with hand-optimized statements, full usage of bind parameters for all literal values, fully transactionalized and batched database writes using the Unit of Work pattern.
Highly Modular
Different parts of SQLAlchemy can be used independently of the rest. You can use the connection pool by itself and deal with raw connections; or you can use the SQL construction language by itself, either in direct conjunction with one or more database connections or as standalone constructs which return their string-compiled contents. While SQLAlchemy has a great ORM provided, the other parts have no dependency on it; its usage is completely optional. Simpler facades for the ORM can be used as well, such as the ActiveMapper and SqlSoup extension modules. SQLAlchemy is architected in an open style that allows plenty of customization, supporting user-defined datatypes, custom SQL extensions, and a plugin system which can augment or extend any functionality including SQL expressions an
I think pie menus would work well in the OLCP user interface.
Pie menus aren't radical or new, however they're a radial but non-standard menu UI that's been empirically tested and shown to be faster and less error prone than linear menus.
Since the OLPC interface runs on a small screen, and uses the screen edges to frame and control the user interface, one issue that needs to be properly addressed is the screen edge problem:
You can pop up pie menus in the screen corners or along the screen edges, by slicing them into 1/4 or 1/2 sized pies, so all of their items are in selectable directions. Starting the pie menu selection gesture near the edge or corner limits the number of directions you can move, but gives you the entire screen area to use as "leverage" to control the selection.
On the other hand, if you pop up a menu in the center of the screen, you can move in 8 (or so) different directions, but only half as far (so you can't get as much "leverage").
The way pie menus directly exploit Fitts' Law enables users and designers to make some fortunate trade-offs: Pie menu users can increase the distance of motion to gain more "leverage" (precision and accuracy of selection): trading off selection speed to reduce the error rate. Pie menu designers can trade off selection speed and error rate to increase number of items, and the additional leverage of edge and corner menus makes it possible to put more items on them (within reason).
Absolutely right! Apple used to have some great and serious people working on HCI, and made a lot of important advances (like HyperCard), which they have totally abandoned. Today, their user interfaces look and feel like they were designed by a bunch of cocaine-addled advertising executives.
Case in point: Why didn't the QuickTime team clean up their act after being inducted into the User Interface Hall of Shame? They have had 7 years to clean up that mess, but it's just gotten worse and worse!!!
It's a great thing that the OLPC project is trying to learn from Apple's mistakes instead of blindly emulating them.
Amid much fanfare, Apple recently released a beta version of the QuickTime 4.0 Player. Intended to showcase the technological improvements of the QuickTime 4.0 multimedia technology, the QuickTime 4.0 Player sports a completely redesigned user interface. The new interface represents an almost violent departure from the long established standards that have been the hallmark of Apple software. Ease of Use has always been paramount to Apple, but after exploring the QuickTime 4.0 Player, the rationale behind Apple's recent "Think Different" advertising campaign is now clear.
While there are some who would conclude that the revised interface represents innovative thinking at Apple, we would have to conclude otherwise. There is nothing innovative about the user interface of the QuickTime 4.0 Player; the developers adopted the same misguided principles employed in IBM's RealThings, copied some of the same features we critiqued in our reviews of IBM's RealPhone and RealCD, and added a few new follies of their own.
We recognize that some visitors may disagree with our assessment of particular features of the application and we invite your feedback. Comments can be sent to quicktime@iarchitect.com.
For the sake of accuracy, it should be noted that the following is a review of the user interface of the QuickTime 4.0 Player, not the QuickTime technology itself.
Inducted 25-May-1999
QuickTime 4.0 Player One look at QuickTime 4.0 Player and one must wonder whether Apple, arguably the most zealous defender of consistency in user interface design, has abandoned its twenty-year effort to champion interface standards. As with IBM's RealThings, it would seem that appearance has taken precedence to the basic principles of graphical interface design. In an effort to achieve what some consider to be a more modern appearance, Apple has removed the very interface clues and subtleties that allowed us to learn how to use GUI in the first place. Window borders, title bars, window management controls, meaningful control labels, state indicators, focus indicators, default control indicators, and discernible keyboard access mechanisms are all gone. According to IBM's RealThings, and apparently to Apple, such items and the meaningful information they provide are merely "visual noise and clutter". While the graphical designer may be pleased with the result, the user is left in a state of confusion: unable to determine which objects are controls, which are available at any point in the interaction, how they are activated, where they may be located, and how basic functions can be performed.
The QuickTime 4.0 Player sports a consumer interface, designed so that it "looks like" a physical consumer product. Apologists for this design philosophy maintain that users will more readily be able to transfer their knowledge of real-world objects to the software. Unfortunately, the apologists fail to recognize that there are two likely consequences of this approach: (1) the user is unable to transfer his or her existing knowledge of computer interaction, and (2) the software becomes needlessly subject to the limitations of the physical device.
MacOS (and OS/X) most certainly IS boring and unoriginal. Mac OS/X is based on the ancient NeXT Step window system, which was design a long long time ago. Apple has totally stagnated, and has been resting on their laurels for many years now. All their focus is on meaningless fluff and window dressing, instead of usability and empowering users.
For example, take the QuickTime player, which has only gotten worse and more obnoxious in the service of marketing iTunes and upgrades and advertisements, since it was rightfully inducted into the User Interface Hall of Shame.
Why hasn't Apple finally admitted that it's a reasonable idea to let users resize windows with the other three corners? They were wrong in 1984 to have only one resize corner, they were still wrong in 1994, still wrong in 2004, and they are still wrong in 2006. Like George W Bush, they're too vain to admit they made a mistake and correct it. Can ANYONE here give me one good argument why Mac windows can only be resized from the lower right corner?
Bill Buxton put it well: it is an unworthy design objective to aim for anything less than trying to do to the Macintosh what the Macintosh did to the previous state of the art.
What's annoying is how the politically-oriented industry-driven XSD committee ignored years of computer science and language theory, and instead came up with an ugly mish-mash of inconsistent hacks and kludges held together with scotch tape and bailing wire.
What's delightful is how the maverick geniuses who came up with Relax/NG solidly based it on "hedge automata theory", which is an extension of "tree automata theory" that applies to XML data.
-Don
Re:Maximizing Composability and Relax NG Trivia
on
Tim Bray Says RELAX
·
· Score: 1
You can't get around the fact that Java simply does not have those many important features I listed (and linked to their definitions on Wikipedia), which are all extremely useful for implementing things like Relax/NG validators.
James Clark, the guy who wrote the Haskell code, is the SAME guy who wrote the Java code, and he's written a whole lot of other complex Java code, as well as many other languages, and also designed and implemented many XML standards. FYI, he served as the technical lead of the original W3C XML Working Group and as the editor of the XSLT and XPath recommendations.
Kiddo, you have no idea who you're calling a "poor (or stubborn) programmer". James Clark is one of the best programmers on the planet, who has written some of the most important code that's run by millions of people every day. Have you ever heard of Expat, the XML parser? Or XSLT? And no, James Clark is NOT the guy who founded Netscape. That Jim Clark just made millions of dollars off of the open source code generously designed, written and shared by James Clark.
If you peek under the hood of high-profile open-source projects such as Mozilla, Apache, Perl, and Python, you'll find a little program called "expat" handling the XML parsing. If you've ever used the man command on your GNU/Linux distribution, then you've also used groff, the GNU version of the UNIX text formatting application, troff. If you've ever done any work with SGML, from generating documentation from DocBook to building your own SGML applications, you've undoubtedly come across sgmls, SP, and Jade.
Whether you've heard of him or not (and mostly likely, you haven't), James Clark (below right) has made your life easier. In addition to authoring these and other widely used open-source tools (see http://www.jclark.com/ for a complete list), Clark served as the technical lead of the original W3C XML Working Group and as the editor of the XSLT and XPath recommendations. He recently founded Thai Open Source Software Center (http://www.thaiopensource.com/). His latest project is TREX, an XML schema language. Clark sat down with Eugene Eric Kim to discuss markup languages, the standardization process, and the importance of simplicity.
DDJ: How did you get involved with SGML?
JC: I was interested in using SGML as a replacement for one part of what groff was doing. Then I got Charles Goldfarb's book, The SGML Handbook, and I thought, "Hmm, this is an interesting thing. Let's see if I can write a program for it." Then Charles Goldfarb released his ARCSGML SGML parser, and I started working with that. The more I worked with it, the more I felt it needed improvements and bug fixes, and nobody else seemed to be doing that. There seemed to be a real need for turning a research-worthy tool into more of a production-quality tool, and that turned into sgmls. Working with sgmls, I got more and more dissatisfied with its basic internal structure. There were some things in SGML that would have been very hard to implement within sgmls, and I felt that I really understood how SGML parsing worked, and so I produced a completely new SGML parser, SP.
DDJ: Did you feel like there were any major itches that you got to scratch with the specification of XML?
JC: I knew how insanely complex writing an SGML parser was. SGML is really doing something very simple. It's providing a standard way to represent a tree, and your nodes have a label with names and they can have attributes. That's all it's doing. It's not a complicated concept. Yet SGML manages to make writing something that implements it into a several-man-year project.
A lot of the features do have a reasonable mo
Re:Maximizing Composability and Relax NG Trivia
on
Tim Bray Says RELAX
·
· Score: 1
You have to remember we're talking about Java code written by James Clark here, not John Q. Random programmer. Clark is an excellent Java programmer, and has written many lines of hard core Java and C code (and many other langauges like Scheme and Haskell), implementing a long line of SGML an XML standards, including DSSSL, XSLT, XPath, Expat, etc. And it's all open source code, so you can go look at it determine how good a programmer he is by yourself.
Anyway, Java IS a bad language, especially compared to Haskell. Sheez, what planet are you from?
-Don
Re:Maximizing Composability and Relax NG Trivia
on
Tim Bray Says RELAX
·
· Score: 1
Not so much of a Java flame as a Haskel plug. Everything I said about Haskel and Java is true. I even counted the number of lines of code. How is that a flame?
-Don
Re:Relax NG: Design-by-Inspired-Individuals
on
Tim Bray Says RELAX
·
· Score: 1
Ahem...
DTDs are more powerful than XSD's, in that they support interleaving. Relax/NG also supports interleaving, but XSD does not. The XSD designers originally believed that interleaving was too computationally expensive to support efficiently, which is why left it out. But they were wrong, and James Clark showed them how to do it, by using lazy automata construction. It's fucking brilliant. I've read the Relax/NG Haskel code as well as the Java implementation, and it's really beautiful stuff. You're totally missing out, trying to construct a radio with stone knives and bear skins, if you're still stuck with XSD's.
So just why are you so inflexible, close minded, and incapable of using a better technology than XSD? If there was a good reason to use Relax/NG instead of XSD, and you really wanted to switch, could you? Would you? Why or why not?
It sounds to me like you made a horrible investment in XSD and got screwed by it, and you don't want to hear about how happy everybody is about Relax/NG. Why the long face?
-Don
Re:Relax NG: Design-by-Inspired-Individuals
on
Tim Bray Says RELAX
·
· Score: 1
Why are you so afraid to post your ridiculous arguments under your real name?
I'm so glad you asked. Have you bothered to read the discussion of the design that went into Relax/NG? It was specifically designed to address many of the shortcomings and limitations and complexities of XSD.
One good metric of simplicity and power is "composability", as defined by James Clark in his description of Relax/NG. (See my other post on the subject, where he defines that term, and goes into a lot of detail about the reasons behind the design.)
James Clark wrote about maximizing composability:
First, a little digression. In general, I have made it a design principle in TREX to maximize "composability". It's a little bit hard to describe. The idea is that a language provides a number of different kinds of atomic thing, and a number different ways to compose new things out of other things. Maximizing composability means minimizing restrictions on which ways to compose things can be applied to which kinds of thing. Maximizing composability tends to improve the ratio between functionality on the one hand and simplicity/ease of use/ease of learning on the other.
Another good metric of the simplicity, readability and writability is the "syntactic surface area" of the syntax: XSD does not have a non-XML syntax, while Relax/NG has the compact syntax, which is MUCH easier to read and write than anything that uses XML syntax.
Dude, your arguments are coming from total ignorance and stupid anger. You obviously know very little about computer science, language design and human factors. Please tell us your name so we can know who could possibly be such a fool, or shut up and stop spouting such bullshit.
Slashdot Mirror
Are you trying to deny that other languages like Python and Ruby are flexible, extensible and easy to use? In fact, they're much more flexible, extensible and easier to use than PHP, by a long shot.
There's nothing special about PHP that doesn't apply to other languages, and you can't deny that PHP is severely flawed in its own peculiar ways.
I'm not judging PHP by rumor, nor trying to compare it to other languages I don't know. Anyone with enough perspective to compare PHP with other languages can understand and admit to PHP's limitations. Why can't you? Is PHP the first and only language you ever learned? If you had anything decent to compare it with, you would realize how bad PHP sucks in comparison to the alternatives.
-Don
Another point about your buggy image resizer web page: Your disclaimer is a lie!
Then how do you explain this error message:
Is it just my impression, or are most PHP apologists really as incompetent as you?
-Don
By the way, your amazing image resizer web service that you advertise in your link has some wee bugs. Wow, that's some really amazing powerful PHP code you wrote there, which really demonstrates your mastery of PHP, and shows how much better PHP is than any other language. There's no way anyone could have done that in any language besides PHP, because PHP is just so powerful and easy to use, when it comes to resizing images. You must have to pay a lot in web hosting fees to run such a sophisticated web service. Have you already received thousands of dollars in PayPal donations from your amazing service, or sold your great online image resizing idea to Kleiner Perkins as the next big Web 2.0 startup company?
-Don
Ahem -- REALITY CHECK: YOUR stupid PHP-fanboy post was moderated -1 Troll, and the pro-Java, pro-Apache post was moderated +1 Interesting.
Please explain why you think -1 > 1? Is there some quirk in PHP's numeric handling, type conversion, identity and comparison operators that has you confused about the order of integers?
You're the worst kind of PHP apologist, with your reality-denying Rumsfeldian arguments. The whole point of this discussion is the PHP developer's stubborn refusal to address security issues, and their consistent mis-behavior of sweeping problems under the rug and refusing to fix bugs. The fact that PHP is widely used makes it EVEN MORE IMPORTANT to fix its bugs and design flaws. But as your twisted argument goes, PHP's popularity is an EXCUSE for having so many bugs and design flaws. Blame the media for the casualties in Iraq, why don't you?
Nobody's arguing about whether or not PHP is buggy and badly designed. That's simply an undisputed fact. But you're trying to claim its outrageous number of bugs and design flaws is OK because PHP is widely used, and that's totally ridiculous, and outright negligent.
-Don
Absolutely right. The effort required to "fix" PHP is gargantuan (and futile) compared to the effort of simply learning a better language that doesn't need to be "fixed". It's ridiculous to put any more effort into PHP, when so many excellent alternatives are immediately available.
Monolinguistic newbie PHP apologists: There is nothing "special" about PHP. The feeling of power it gives you is from the COMPUTER, not the language. Every other programming language gives you the EXACT same feeling of power. PHP is not any easier to learn than most other modern languages, in fact it's much harder to learn to deal with all of its nuances, quirks, bugs, limitations, and work around all of its design flaws, which you don't have to worry about with better languages like Ruby and Python, which are both extremely easy to learn and use. PHP's simplicity is an ILLUSION, and its flaws are a FACT.
Case in point: Ruby's ActiveRecord and Python's SQLAlchemy make it MUCH EASIER and also MUCH SAFER to access SQL databases, than anything PHP has. And that's not because nobody's bothered to write a decent ORM in PHP: they have, and they failed miserably. If you think you can do a better job than Zend's ZActiveRecord Boondoggle, then go ahead and try, but even the charlitans who DESIGNED PHP were so overconfident in its abilities and broadsided by its limitations and design flaws that they didn't even understand themselves before they tried and failed.
-Don
Wrong: PHP, Perl and Python and Java are all written in C, not C++. Do you know ANY other language than PHP? If not, you're just ignorant: why do you think your opinion matters?
You're also wrong that PHP rules on "website/browser-server". First of all, nobody runs PHP in the browser. Second of all, PHP doesn't rule on the server: it totally sucks compared to the alternatives.
Compare PHP to other languages like Python, Perl, Java and Ruby: it's much worse, buggier, and poorly designed compared to all the alternatives.
If you really think PHP doesn't suck, then please explain which database interface you use in PHP, and how it compares to SQLAlchemy and ActiveRecord in terms of power, security, flexability, ease of use, and performance. That's my point: PHP totally sucks in comparison to the alternatives, and its majorly fucked up design flaws and broken object model make it impossible to do anything in PHP like the popular and powerful ActiveRecord and SQLAlchemy do.
While you're at it, please explain why you believe that PHP's object model is not totally fucked up, and justify its bugs and limitations with respect static methods as I described above, explain why the PHP team refuses to fix those design flaws, and demonstrate how you'd work around those flaws to write an ActiveRecord-like ORM, the way Zend attempted to do but miserably failed. Maybe you can teach the charlitans at Zend a thing or two, if you're such a hot PHP expert.
-Don
PHP can't force to to write good code, but it certainly forces you to write bad code.
Case in point: Zend's ZActiveRecord Boondoggle. PHP's object model is so broken that it can't support an ORM as simple and easy to use as Ruby's ActiveRecord, let alone one as powerful and flexible as Python's SQLAlchemy.
How do PHP's "numerous other data abstraction layers" compare to ActiveRecord and SQLAlchemy? Why can't Zend themself figure out how to implement their own version of ActiveRecord? It's because a fatal flaw in the design of the PHP language, that's why.
It's no wonder so many people are abandoning PHP for better languages like Ruby and Python.
-Don
The article says:
Parse that carefully. It says the PHP project is not trying to conceal the fact. What fact? The fact that PHP has been implemented in a very unsafe way.
Oh, that fact. Yes, it's a pesky little fact, indeed. But the fact that they're arguing about whether or not they're trying to conceal it, instead of arguing about how to best address that inconvenient little truth, is a big problem.
PHP's implementation is unsafe, fundamentally flawed, insecure, and it's badly designed to its very core. That's a fact. Any apologist who counters "but it gets the job done" is ignorant of PHP's problems, and ignoring the fact that there are many other open source languages out there that are much better designed, also get the job done, are at least as easy to learn and use as PHP, without all the bugs and security holes, and with many important advantages.
There's no reason to be using PHP to write new software, except ignorance of other languages and refusal to learn.
-Don
The effect he has on the success rate of attacks pales in comparison to the effect the PHP's long track record of horrible bugs and design flaws has on the success rate of attacks. Blame the people who wrote the bugs and mis-designed all the security holes and language mis-features, not the people who want to fix them.
If he raises people's awareness enough that some people STOP USING PHP, then he will have had a positive effect.
-Don
As long as we were pulling numbers out of our asses: That $10-$20k increase doesn't nearly make up for the $40k decrease because you're dumb enough to use a horrible language like PHP.
-Don
If I didn't use and program in php, then I wouldn't know first hand what was so horrible about it. You're not qualified to complain about a language (or anything else) if you don't know what's wrong with it from first hand experience.
Back to the discussion: So which database interface do you use in PHP, and how is it better and more secure than SQLAlchemy or ActiveRecord?
-Don
http://www.urbandictionary.com/define.php?term=sti ck+a+fork+in+it
-Don
[I posted this earlier in the context of PostgreSQL Slammed by PHP Creator, but it bears repeating, since the charlitans at Zend still haven't addressed the problem, and NEVER WILL. Would anyone from Zend please finally comment, and explain just how PHP's plan for a database solution is better and more secure than Python's SQLAlchemy? -Don]
The creators of PHP are morons, and their support company Zend is dishonest and incompetent. The ZActiveRecord boondoggle demonstrates exactly what I mean: They can't program their way out of a paper bag, an don't even understand the limitations of the very language that they haphazardly "designed".
It makes me laugh that Lerdorf would slam Postgres, because the PHP designers have no understanding of object oriented programming or databases: instead they invent half baked cargo-cult designs, which are naive reactions to other systems they don't understand: they try to ape their surface features without understanding the reasons behind the way they're designed.
PHP references were thrown in as a band-aid to work around the horrible design flaw that arrays and objects were foolishly DEEP COPIED by default. If you pass or return an array from function to function, its contents are DEEP COPIED, which is EXTREMELY inefficient and leads to all kinds of horrible bugs because it's the last thing a sane programmer would expect. So instead of fixing the design flaw in PHP, they add "references" that LOOK and SOUND like C++ references, but actually are completely different, again misleading programmers into thinking they understand what's going on, but working totally differently than a sane person would expect. PHP references are actually half baked symbol table references. The sloppy implementation caused many bugs that CORE DUMP PHP! PHP references were so poorly thought out and badly designed, that there were many edge conditions that they hadn't considered, that simply didn't work together, caused memory leaks and core dumps, and had useless and confusing semantics: callers passing references, functions declaring that they take references, functions returning references, etc. Compare that to C++'s simple and consistent definition of references in term of pointers. The only way to make a PHP reference to an object is to put it in a variable -- you can't make a reference to a field of an object or the return value of a function without storing it in a temporary variable -- totally unlike C++, and totally stupid.
PHP's object oriented programming system is a half-baked imitation of C++'s object model, haphazardly designed by charlitans who had no clue about the fundamentals of object oriented programming, elegant language design or efficient implementation. First of all, if you're going to try to imitate an existing design without understanding it, then for god's sake, at least imitate a language whose object system doesn't suck, and a language that has similar semantics to the language you're trying to kludge. C++ is a static compiled language, and its object system deeply reflects that fact. (That is to say, there's very little reflection beyond RTTI, because the compiler throws all the interesting stuff away! And C++'s oop design had to make many horrible compromises because the C++ object system was designed to map directly into C se
Since you're wise enough to dump PHP and switch to Python, and you're looking for a good way to do SQL, then you should definitely check out SQLAlchema. It's light years ahead of Ruby's "ActiveRecord", plus it has several different front-ends that simplify it and make it as easy to use as Ruby's ActiveRecord and Python's SQLObject, while still allowing you to use its much more advanced features.
Not only is it much more powerful than Ruby's ActiveRecord (which is causing people to abandon PHP in droves), but SQLAlchemy is astronomically better than anything PHP has, and PHP will never have anything that even approaches ActiveRecord because of foolish bugs and design flaws that the charlitans on the PHP team stubbornly refuse to fix. (As described in detail in Zend's ZActiveRecord Boondoggle.)
-Don
Bricks can be used to build housing, so the downside of bricking an OLPC is not so bad.
-Don
I think pie menus would work well in the OLCP user interface.
Pie menus aren't radical or new, however they're a radial but non-standard menu UI that's been empirically tested and shown to be faster and less error prone than linear menus.
Since the OLPC interface runs on a small screen, and uses the screen edges to frame and control the user interface, one issue that needs to be properly addressed is the screen edge problem:
You can pop up pie menus in the screen corners or along the screen edges, by slicing them into 1/4 or 1/2 sized pies, so all of their items are in selectable directions. Starting the pie menu selection gesture near the edge or corner limits the number of directions you can move, but gives you the entire screen area to use as "leverage" to control the selection.
On the other hand, if you pop up a menu in the center of the screen, you can move in 8 (or so) different directions, but only half as far (so you can't get as much "leverage").
The way pie menus directly exploit Fitts' Law enables users and designers to make some fortunate trade-offs: Pie menu users can increase the distance of motion to gain more "leverage" (precision and accuracy of selection): trading off selection speed to reduce the error rate. Pie menu designers can trade off selection speed and error rate to increase number of items, and the additional leverage of edge and corner menus makes it possible to put more items on them (within reason).
-Don
Absolutely right! Apple used to have some great and serious people working on HCI, and made a lot of important advances (like HyperCard), which they have totally abandoned. Today, their user interfaces look and feel like they were designed by a bunch of cocaine-addled advertising executives.
Case in point: Why didn't the QuickTime team clean up their act after being inducted into the User Interface Hall of Shame? They have had 7 years to clean up that mess, but it's just gotten worse and worse!!!
It's a great thing that the OLPC project is trying to learn from Apple's mistakes instead of blindly emulating them.
-Don
Interface Hall of Shame
- QuickTime 4.0 Player -
MacOS (and OS/X) most certainly IS boring and unoriginal. Mac OS/X is based on the ancient NeXT Step window system, which was design a long long time ago. Apple has totally stagnated, and has been resting on their laurels for many years now. All their focus is on meaningless fluff and window dressing, instead of usability and empowering users.
For example, take the QuickTime player, which has only gotten worse and more obnoxious in the service of marketing iTunes and upgrades and advertisements, since it was rightfully inducted into the User Interface Hall of Shame.
Why hasn't Apple finally admitted that it's a reasonable idea to let users resize windows with the other three corners? They were wrong in 1984 to have only one resize corner, they were still wrong in 1994, still wrong in 2004, and they are still wrong in 2006. Like George W Bush, they're too vain to admit they made a mistake and correct it. Can ANYONE here give me one good argument why Mac windows can only be resized from the lower right corner?
Bill Buxton put it well: it is an unworthy design objective to aim for anything less than trying to do to the Macintosh what the Macintosh did to the previous state of the art.
-Don
What's annoying is how the politically-oriented industry-driven XSD committee ignored years of computer science and language theory, and instead came up with an ugly mish-mash of inconsistent hacks and kludges held together with scotch tape and bailing wire.
What's delightful is how the maverick geniuses who came up with Relax/NG solidly based it on "hedge automata theory", which is an extension of "tree automata theory" that applies to XML data.
-Don
You can't get around the fact that Java simply does not have those many important features I listed (and linked to their definitions on Wikipedia), which are all extremely useful for implementing things like Relax/NG validators.
James Clark, the guy who wrote the Haskell code, is the SAME guy who wrote the Java code, and he's written a whole lot of other complex Java code, as well as many other languages, and also designed and implemented many XML standards. FYI, he served as the technical lead of the original W3C XML Working Group and as the editor of the XSLT and XPath recommendations.
Kiddo, you have no idea who you're calling a "poor (or stubborn) programmer". James Clark is one of the best programmers on the planet, who has written some of the most important code that's run by millions of people every day. Have you ever heard of Expat, the XML parser? Or XSLT? And no, James Clark is NOT the guy who founded Netscape. That Jim Clark just made millions of dollars off of the open source code generously designed, written and shared by James Clark.
Here is a brilliant interview with James Clark from Dr. Dobb's Journal. I've included some of my favorite parts, but the entire interview is fascinating and well worth reading. A Triumph of Simplicity: James Clark on Markup Languages and XML:
You have to remember we're talking about Java code written by James Clark here, not John Q. Random programmer. Clark is an excellent Java programmer, and has written many lines of hard core Java and C code (and many other langauges like Scheme and Haskell), implementing a long line of SGML an XML standards, including DSSSL, XSLT, XPath, Expat, etc. And it's all open source code, so you can go look at it determine how good a programmer he is by yourself.
Anyway, Java IS a bad language, especially compared to Haskell. Sheez, what planet are you from?
-Don
Not so much of a Java flame as a Haskel plug. Everything I said about Haskel and Java is true. I even counted the number of lines of code. How is that a flame?
-Don
Ahem... DTDs are more powerful than XSD's, in that they support interleaving. Relax/NG also supports interleaving, but XSD does not. The XSD designers originally believed that interleaving was too computationally expensive to support efficiently, which is why left it out. But they were wrong, and James Clark showed them how to do it, by using lazy automata construction. It's fucking brilliant. I've read the Relax/NG Haskel code as well as the Java implementation, and it's really beautiful stuff. You're totally missing out, trying to construct a radio with stone knives and bear skins, if you're still stuck with XSD's.
So just why are you so inflexible, close minded, and incapable of using a better technology than XSD? If there was a good reason to use Relax/NG instead of XSD, and you really wanted to switch, could you? Would you? Why or why not?
It sounds to me like you made a horrible investment in XSD and got screwed by it, and you don't want to hear about how happy everybody is about Relax/NG. Why the long face?
-Don
Why are you so afraid to post your ridiculous arguments under your real name?
I'm so glad you asked. Have you bothered to read the discussion of the design that went into Relax/NG? It was specifically designed to address many of the shortcomings and limitations and complexities of XSD.
One good metric of simplicity and power is "composability", as defined by James Clark in his description of Relax/NG. (See my other post on the subject, where he defines that term, and goes into a lot of detail about the reasons behind the design.)
James Clark wrote about maximizing composability:
Another good metric of the simplicity, readability and writability is the "syntactic surface area" of the syntax: XSD does not have a non-XML syntax, while Relax/NG has the compact syntax, which is MUCH easier to read and write than anything that uses XML syntax.
Dude, your arguments are coming from total ignorance and stupid anger. You obviously know very little about computer science, language design and human factors. Please tell us your name so we can know who could possibly be such a fool, or shut up and stop spouting such bullshit.
-Don
PS: Fucktard is one word, you anonymous asshat.
It's good for transmitting information/energy, but it's not good for storing it.
-Don