Slashdot Mirror


PHP 5.1.0 Released

kv9 writes "A new release of PHP5 is available. This version includes over 400 bugfixes, performance improvements over the 5.0.x branch, new date handling code, new versions of PCRE/SQLite/PEAR and over 30 new core/extension functions. A number of security fixes are also present and users are recommended to upgrade."

49 of 275 comments (clear)

  1. mySQL support by Anonymous Coward · · Score: 5, Funny

    MySQL support has been droped in favor of using simple flat text files. The performance increase from this has been HUGE and the feature set is the same.

    1. Re:mySQL support by ajs318 · · Score: 2, Informative

      What is it with the MySQL bashers around here? Have you actually used it or are you just content to parrot what you have heard elsewhere?

      For read-only, or even read-mostly, MySQL is blisteringly fast. It slows down when doing many INSERT or UPDATE queries on large tables because the whole table is held in one file, which has to be locked during a write and so slows things down.

      On Linux, with a disk caching policy of "Never, ever commit anything unless you have to swap something from RAM, or are about to umount the file system" and enough RAM to cache the whole table file, MySQL writes almost as fast as it reads. OSes with more conservative policies, such as insisting to decache often and verifying before releasing the RAM, obviously won't be so fast {but who'll be laughing at who when the power comes back on?}.


      Ah, shit, I'm feeding a troll, aren't I? I wasted fifteen minutes of my life and I can never have them back .....

      --
      Je fume. Tu fumes. Nous fûmes!
    2. Re:mySQL support by CyricZ · · Score: 4, Insightful

      A lot of people who criticize MySQL have directly used MySQL. What we've found is that for lighter tasks (such as many webpages), SQLite often works quite well. And once/if you need a database system that's more capable, it's best just to move to PostgreSQL.

      The recent Oracle/InnoDB and MySQL AB/SCO debacles have also made many potential MySQL users weary. There are many users who are now questioning how viable MySQL will be in the near future, both from a technical standpoint with regards to the InnoDB purchase by Oracle, and from a legal standpoint concerning their dealings with SCO. SQLite and PostgreSQL do not suffer from such unknowns.

      --
      Cyric Zndovzny at your service.
    3. Re:mySQL support by kpharmer · · Score: 3, Interesting

      > For read-only, or even read-mostly, MySQL is blisteringly fast.

      I think you mean that when doing lookups of a very small (less than 1%) set of data from a single table with simple queries that mysql understands the b-tree index in myisam or oracle's innodb is as fast as any other database. In the case of myisam maybe a little more, in the case of innodb maybe a little less.

      I'm sure you don't mean that when selecting 10% of the data of a single table of the database (thereby unable to do b-tree lookups) and doing table scans instead that it is very fast at all. It might be competitive with postgresql, firebird, and sqllite there, but falls *completely* behind oracle, db2, informix, sqlbase, and now sql server when using partitioning. Or parallelism.

      And you probably didn't mean that it was fast when handling complex queries. It's notoriously bad about handling them.

      > On Linux, with a disk caching policy of "Never, ever commit anything unless you have to swap something
      > from RAM, or are about to umount the file system" and enough RAM to cache the whole table file, MySQL writes
      > almost as fast as it reads. OSes with more conservative policies, such as insisting to decache often and
      > verifying before releasing the RAM, obviously won't be so fast {but who'll be laughing at who when the power
      > comes back on?}.

      Wouldn't this be better resolved through a storage adapter with 128 mbytes or more of battery-backed disk cache, and then turning on write-caching - and having your storage system handle it? In this scenario you are very unlikely to corrupt or lose data due to a power outage or crash.

      And you had mentioned large files - what if you've got a 10 gbyte file? Doing lots of concurrent writing to it? This won't fit into memory, so now you're back to the writing-at-the-speed-of-a-snail speed.

      > What is it with the MySQL bashers around here?

      - too much hype
      - company leadership that covered up missing *basic* features in the product for years insisting people don't need them anyway
      - unsubstantiated claims (blisteringly fast) that end up being gross exaggerations at best
      - most non-ansi implementation in the marketplace
      - deliberately complex dual-licensing scheme that doesn't comply with GPL
      - inability to handle even moderately complex queries
      - absolutely bizarre exception handling issues (silent truncations, etc)

      MySQL is a success story, but mostly a marketing success story. It started as a sql layer on top of flat files - not intended to be a database management system - just a file management system. And then people applied this tool to database management - without even the most basic of features (views, transactions, etc).

      This isn't to say that people can't successfully use it for database management. Of course you can. You can also pull stumps with a ford explorer. It's just that the explorer wasn't really designed for pulling stumps, and a tractor does it *so* much better.

    4. Re:mySQL support by Bake · · Score: 3, Informative

      Can you just do an SQL dump from MySQL and put it into Postgre, no problems?

      Actually, this can be tricky due to MySQL's tendencies to massage data to fit comfortably into tables. Using defaults such as 0000-00-00 in date fields instead of NULL, allowing values such as 2005-02-30 (i.e. 30th of February).

      If you have such values in your MySQL database and intend to migrate that data into PostgreSQL, you first have to make the data conform to the C part of ACID (Consistency) before moving it to other RDBMS systems.

  2. Sendmail by jrockway · · Score: 3, Funny

    > A number of security fixes are also present

    I think we've finally found a replacement for the security disaster known as sendmail -- PHP.

    --
    My other car is first.
    1. Re:Sendmail by Anonymous Coward · · Score: 2, Insightful

      That's almost certainly a problem with your code, extra headers being injected because of improper input validation.

      Always check that your input is well-formed, an email address is actually an email address and so on.

      If nothing else, stripping newlines and carriage returns will thwart most of those bots.

      Unfortunately it's a common problem, but if you code properly it's entirely avoidable.

    2. Re:Sendmail by davegaramond · · Score: 2, Informative

      Blame those brain-dead PHP "architects" for designing the API for the sendmail() PHP function. The fourth argument accepts arbitrary headers. The 4th arg is used a lot because the damn function doesn't even provide another argument for the From header! It's easily exploitable because those idiotic PHP "programmers" never check values they send to functions, thus sendmail($to, $subject, $body, "From: $from") is easily exploitable by spammers through injecting nasty values to $from. I hate everything PHP-related.

  3. Many improvement... by masklinn · · Score: 3, Funny

    ...and still no damn fucking namespaces.

    Go PHP, ride on to the 20th century!

    --
    "The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
    1. Re:Many improvement... by Anonymous Coward · · Score: 3, Informative

      They are considering namespaces for PHP 6 - Read the meeting notes here:

      http://www.php.net/~derick/meeting-notes.html

      http://www.corephp.co.uk/archives/19-Prepare-for-P HP-6.html

    2. Re:Many improvement... by g2devi · · Score: 4, Interesting

      Relating to this comment:
      http://developers.slashdot.org/comments.pl?sid=169 325&cid=14113043

      It's true that PHP suffers from various naming conventions, but namespaces might me the answer.

      For PHP 6.0, does anyone know if the core developers are thinking of moving most builtin libraries into namespaces? For instance:
      . . . http://ca.php.net/manual/en/function.oci-commit.ph p
      could be placed in the "builtin\oci" namespace and
      . . . http://ca.php.net/manual/en/function.ocicommit.php
      could be placed in the "builtin\legacy\oci" namespace.

      You could quickly convert all PHP5 to PHP6 simply by adding the line:
      . . . import builtin\*;
      to the top of every file to make all builtin functions global (the way they are in PHP5).

      Apps written in PHP5 would still work without the import, but they'd get a warning (which could be switches off in the php.ini).

    3. Re:Many improvement... by tacocat · · Score: 2, Insightful

      Well put.

      I find it ironic that PHP came out many years ago as a cheap and easy way to make more dynamic web pages with a simpler structure than perl. It was also a greatly reduced structure from perl.

      Then someone added a bunch of MySQL to it, hyped it up as LAMP and now everyone's on that bandwagon. And those that weren't were bitching about how if you want to do a real web application you would be better off using Perl and PostgreSQL.

      And now here we are years alter and from the threads I've seen herein:

      • PHP has some horrible security pitfalls that are now being addressed.
      • MySQL is being dumped for SQLite which is just a flat file system, but then so it Berkeley DB which seems pretty damn fast too
      • PostgreSQL is still the last viable option for a real database that you can afford.
      • And PHP 6 is talking about adding NameSpaces.
      What I see here is that as time marches on, PHP is becoming more difficult to use and more like Perl.

      So when PHP rivals Perl in capability, it will likely rival Perl in complexity as well, only Perl has had 10+ years to settle out the bugs.

      And what simplistic dynamic web page application will come along to replace the original implimentation of PHP? After all, the who reason PHP was so popular was the fact that is was simpler to follow than Perl was. But if it's as complex as Perl.... What next?

      I am beginning to thing that PHP would be better off, in the long run, if they just left themselves to the area of making a bitchin' fantastic scripting tool for making dynamic web pages without trying to compete directly with Perl, Java, and C at the same time. It's kind of stupid.

      Everything has a place.

    4. Re:Many improvement... by bad-badtz-maru · · Score: 2, Interesting


      And another big reason is that the perl libraries (ala CPAN) do not require a recompile of perl itself. I cannot count the number of times I go to do something in PHP only to discover that PHP has to be recompiled with the switch to include such-and-such library. Need to work against an Oracle database in PHP? Bring down the production web servers to install a new PHP with OCI support enabled. Need to work against Oracle in Perl? Just install the appropriate perl module, no need to do anything drastic.

  4. Re:All of my friends and family use the new PHP by masklinn · · Score: 4, Insightful

    Rails still isn't a language, it's a framework.

    (calling Ruby a "toy language" when comparing it to PHP is hillarous though, thanks for the laugh)

    --
    "The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
  5. Beware of PHP 5.1 by Anonymous Coward · · Score: 5, Informative

    You don't have any classes named Date, do you? It's an extremely uncommon name. Good thing we have namespaces.

    http://news.php.net/php.internals/20352

    1. Re:Beware of PHP 5.1 by Tim+Browse · · Score: 3, Funny

      I've only messed around with PHP for my personal website and a small catalogue style website for my parents' business, but I noticed there were no namespaces, so I simulated them by prefixing class/function names with short prefixes, e.g. twbb_GetForumThread() etc.

      I don't envisage having any problems with the new PHP core functions colliding with my names. But then maybe that's because I've worked with other languages that don't have namespaces (e.g. C, which I believe had some brief border-line success/popularity at one point, despite being crippled by lack of namespaces), and also I have a fucking clue what I'm doing. Idiots, on the other hand, will always run into problems.

      That's not to say I wouldn't like to see namespaces in PHP :-)

  6. Bug fixes should go into 5.0.x by halfnerd · · Score: 5, Insightful

    I was under the impression that when using a x.y.z -versioning scheme, bug fixes should be released with increments of z, new features with increments of y, unless they break compatibility, when x should be increased. But when has even PHP done some something in a standard way.

    1. Re:Bug fixes should go into 5.0.x by 1110110001 · · Score: 2, Insightful

      Take a look at the changelog: http://www.php.net/ChangeLog-5.php#5.1.0

      The lines with Added, Changed or Improved are mostly new features, the lines with Fixed are Bugfixes. 1/3 of the Changelog are therefore new features.

      b4n

  7. Adding even more functions? by A+beautiful+mind · · Score: 5, Insightful

    "(...)and over 30 new core/extension functions."

    Ugh. Adding still to the inconsistent, namespace mess, PHP functions have? Worst. Decision. Ever.

    --
    It takes a man to suffer ignorance and smile
    Be yourself no matter what they say
  8. Is any work being done to improve security? by CyricZ · · Score: 2, Insightful

    It's widely known that PHP is used by a lot of "developers" without much background in writing secure software. As such, the coding techniques used are often less than ideal, and have lead to numerous security problems in the past.

    Are the PHP developers actively doing anything to help prevent those without much experience from writing code that can lead to a server being compromised? Not that they should restrict those few developers who do know what they're doing, but they should perhaps be taking a look at making it far more difficult to write dangerous code.

    On the hardware front we have AMD and Intel adding support for non-executable stacks to their processors, for instance. GCC has StackGuard and StackShield. I think it's time for the PHP developers to step up to the place and try to limit the possible damage that can be done when using PHP incorrectly.

    It's easy to continually blame the inexperienced PHP users for writing insecure code. But I do believe that it is up to the PHP developers to use their skills to help mitigate such problems.

    --
    Cyric Zndovzny at your service.
    1. Re:Is any work being done to improve security? by Jotii · · Score: 2, Interesting

      The main reason for PHP being insecure is the huge amount of functions for "securing" form data before using it in an SQL query. It's just comical that both mysql_escape_string() and mysql_real_escape_string() exist. PHP should be purged from all of the unused and misused functions soon, or it will never be safe.

      --
      [sig]
    2. Re:Is any work being done to improve security? by __aaxwdb6741 · · Score: 2, Insightful

      It is also widely known that many server administrators are known to install many applications as root. PHP and apache, among many others.

      Who should be held responsible for THAT? (Set an X)
      [ ] The Apache developers?
      [ ] The Linux developers?
      [ ] The server "administrator"?

    3. Re:Is any work being done to improve security? by Anonymous Coward · · Score: 2, Informative

      "Are the PHP developers actively doing anything to help prevent those without much experience from writing code that can lead to a server being compromised?"
      They are doing quite a bit actually. PHP6 will see a full input_filter mechanism added, safe_mode (misleading name) removed, and other substantial changes that will deeply improve security for programmers.

      In addition, there is discussion of adding namespaces in php6, a feature that would easily improve security in virtually every app by preventing unintended variable overlaps.

      The PHP Internals team takes security very seriously, and is merging the majority of the PHP Hardened script for just that reason.

  9. Power? by Grendel+Drago · · Score: 2, Insightful

    It's really vague to compare two languages' "power". The only definitive comparison you can make is whether they're both Turing-complete. In that case, Perl = C = INTERCAL = Unlambda.

    --
    Laws do not persuade just because they threaten. --Seneca
    1. Re:Power? by 00lmz · · Score: 2, Interesting

      Yes, but as Alan Perlis said in one of his epigrams...

      Beware of the Turing tar-pit in which everything is possible but nothing of interest is easy

      Using your example, Perl is as complete as C, but IMHO interesting things are easier to do in Perl (or ruby, for that matter).

  10. Advances/Alternative to the server by Kunta+Kinte · · Score: 4, Interesting
    PHP's big problem is not language features anymore. It's the lack of innovation in the PHP server program.

    Zend refuses to add basic features such as a basic accelerator ( PHP scripts get recompiled on every request ). In fact, there was a rumor that Zend bought and killed http://sourceforge.net/projects/turck-mmcache/, the best accelerator out there because it competed with their commercial product.

    I understand that money has to be made for development to continue, but that's no way to compete.

    PHP server needs true session and application scope variables. File-based session variables it has right now means that any variable that's not serializable ( eg. file descriptor ) can not be saved in the session scope. This is a huge problem. It results in developers making countless round trips to their database to serialize data, and hence making PHP scripts more dependant on close/performant database in general. There was an mmap based solution being worked on, but haven't heard much about it lately.

    Other web environments have had these features for years.

    I'm guessing that that sought of restriction on the PHP server will continue until an alternative server is developed and begins to gain popularity.

    --
    Based on upvotes, Ageism is the only "-ism" Slashdotters care about and think isn't SJW
  11. OO by smallguy78 · · Score: 4, Informative

    I use to use PHP a lot day to day for several years (lamp), and found it kicked the ass of ASP for doing really fast web apps. Bigger web applications however, is where its mechanics started to erode - specically includes and the old module level variables issue.

    PHP 5 brought more OO features but it's still loosely typed and not compiled, meaning its OO features pale in comparison to JSP and ASP.NET. Until these two features are added by default (yes I know there are compilers), I can't really see how people will want to make use of its OO features in a business scenario. It handles strings (atleast in 4) about 50x slower than .net and seems to be stuck between a scripting language and a fully fledged OO language.

    --
    Nothing costs nothing
    1. Re:OO by moro_666 · · Score: 3, Insightful

      you forgot to add that real programming languages are pretty much backward compatible, whereas php's backward compatibility doesn't just suck, it's nearly non-existant. references, oop parent class calls, global variables etc. this language gets ever more messed up with every new version and with zillion little configuration flags that affect the very basic functions and breaks down even the most patient code.

      php has it's good sides but it the long run it's definitely the loser platform from my point of view. even perl is more stable and readable after 3 years of support on the same code (on php you either do very expensive upgrades to the software every time there are some major changes or you do cheap fixes and the code turns into a mess).

      have you ever tried to read a well organized OOP php source that is supposed to work with every version from 4.0 to 5.x ? nope ? give it a try, i'm sure you will fall off the fgging chair.

      i suggest you use something else, use python, use ruby, if you need to kiss your bosses ass you might even use java but keep your fingers away from php while you can.

      --

      I'd tell you the chances of this story being a dupe, but you wouldn't like it.
  12. Did you look at the PHP 6.0 codebase ? by Gopal.V · · Score: 3, Interesting
    Sometime back, I pulled out the CVS HEAD and tried to hack on top of it. Needless to say it looked alien, with all the hash tables walking around with unicode all around. Php 5.1.xx is only a small step, 6.0 is going to really come crashing down.

    I'd like to take this oppurtunity to complain about __autoload in PHP5. It is one functionality which I find tremendously inconvenient when coding something like APC . File inclusions were never supposed to be that dynamic, it ends up with different compilations of the same file for different places it is included in (apparently some are still fighting).

  13. Re:Great, now what about hosting companies by CyricZ · · Score: 4, Insightful

    If you want cutting edge, then you'll most likely need to run your own server.

    Serious hosting companies just can't risk running software that hasn't been widely tested. While there may be benefits from running the new versions of PHP, for instance, it could be a disaster if a security flaw leads to their servers being compromised. An incident like that could financially destroy a small- or medium-sized hosting company. At least the older versions of PHP have undergone more testing than the newer releases.

    --
    Cyric Zndovzny at your service.
  14. PHP Security by shiflett · · Score: 3, Interesting

    Some of us are trying to help the situation by educating PHP developers. For my part, I try to write articles (and make them available for free), give talks at conferences and user groups, and answer questions on mailing lists and forums.

    There's also the PHP Security Consortium, the Zend Framework (which will hopefully include most things on my wishlist as well as solve other problems), and a new input filter extension.

    As BP says, it's a start.

  15. Some more alternatives to MySQL by Elrac · · Score: 4, Interesting
    I apologize for being a bit off topic, but I'd like to throw in a couple of cents' worth on newly emerged alternatives in the "free DB" arena. Hopefully PHP support for these will be forthcoming forthwith:
    • IBM has spiffed up Cloudscape to be somewhat compatible to DB2, renamed it to Derby and is giving it away
    • Oracle is giving away a mildly crippled version of its DB, I don't remember the exact circumstances
    • ADABAS, also known as SAP DB, is now also FOSS
    • Firebird, née Interbase, was freed years ago and is said to be working well and under active development. I don't know why so few people seem to like it.
    • I believe I heard about SQL Server being "free" under some circumstances too, but I'm not sure.
    So... many thanks to MySQL for being a forerunner in the "free DB" department, and more thanks to other, formerly proprietary-only vendors for making their products a little more accessible to the common man!
    --
    When one person suffers from a delusion, it is called insanity. When many people suffer from a delusion it is called Rel
    1. Re:Some more alternatives to MySQL by TheTomcat · · Score: 2, Informative

      PDO is a free solution to most of these. It's slated to go stable this weekend.

      IBM has spiffed up Cloudscape to be somewhat compatible to DB2, renamed it to Derby and is giving it away
      PDO_ODBC, Zend Core for IBM

      Oracle is giving away a mildly crippled version of its DB, I don't remember the exact circumstances
      PDO_OCI, Zend Core for Oracle

      ADABAS, also known as SAP DB, is now also FOSS
      This one, I know very little about..

      Firebird, née Interbase, was freed years ago and is said to be working well and under active development. I don't know why so few people seem to like it.
      PDO_Firebird

      I believe I heard about SQL Server being "free" under some circumstances too, but I'm not sure.
      Correct, it's called "SQL Server 2005 Express Edition", formerly MSDE. (although, I've not tried EE2005, only MSDE -- it worked well)
      PDO_DBLIB

      S

  16. Re:Great, now what about hosting companies by NuclearRampage · · Score: 2, Informative

    You can try http://www.powweb.com/ They usually keep on top of upgrades and have had php5.0 running for a while now.

  17. What's up and coming in PHP6 by Philmeeh · · Score: 2, Informative

    If anybody is interested in what is coming up in PHP6 you can read an overview here. Looks like the main push of the next release is to stop people coding things wrong (by depending on register globals and magic quotes). Oh and the small thing about adding Unicode support. Unfortunately this will probably mean a slower adoption than PHP5 as it is likely to break popular scripts (such as forums, blogs etc) which will mean that Hosting Companies are unlikely to touch it till the script writers update their scripts.

  18. Re:Backgrounds of the PHP developers. by Elrac · · Score: 5, Insightful
    The Zend guys happen to be damn good programmers - have a look at the code of the interpreter
    That sentence illustrates the problem and your lack of understanding of it.

    Design and programming are two distinct disciplines. Some brilliant developers are good at both, but many people, myself included, get too much satisfaction from diving into coding to thoroughly think about what they are embarking on. The result is a program/system/language/whatever that starts with a clean small core but grows ever bigger and uglier as changes are bolted on. I tried PHP a couple years back and was disgusted by it. There's a reason why computer language design is a discipline of an academic subject, Computer Science: A wealth of knowledge has accumulated on how to do this kind of thing "right," and applying that knowledge will usually lead to a better end result.

    Specifically, my beef with PHP summarizes down to: It makes simple things simple in a way that encourages sloppy coding. PHP is to the current would-be Web geek generation what BASIC was to teenage would-be hotshot coders in the late '80s: A way to achieve "gee whiz!" effects easily and cheaply. It's possible to write large, elegant programs in PHP, but that's not what usually happens.
    --
    When one person suffers from a delusion, it is called insanity. When many people suffer from a delusion it is called Rel
  19. I here lot's of bickering about PHP 5 ... by Qbertino · · Score: 4, Insightful

    ... still having no namespaces and lacking in full-blown OOP and all.

    So what?

    PHP is the web generations basic. No more. But no less either.

    Given that loads of very usefull webapps out there are built in PHP
    I'd say the criticisim is mostly inadequate whining. If PHP doesn't
    cut it for your job, take something else. No big deal.

    --
    We suffer more in our imagination than in reality. - Seneca
  20. PHP, is it API or language? by freezin+fat+guy · · Score: 2, Insightful

    Now that PHP is popular it is undergoing something of an identity crisis. Rasmus said it was an answer to "the web problem", a very simple answer. A "right to the point" approach, terse rather than elegant.

    But as more "serious" developers pick it up, more "serious" features are requested.

    The fact is, if you're flexible you can build whatever you need in PHP4. It may not always be the way you prefer to code, but you can do it.

    PHP is what it is. And it won't appeal to everyone. Fortunately there are many other platforms for the unsatisfied. Take your pick.

    If your primary gripe with PHP is that it isn't enough like Java, shut up and use Java. Same for - insert language here -

    I am very interested to see the new framework being promised by Zend and IBM. (http://www.zend.com/php-collaboration/) Can they really deliver on their promises? If not, I do predict a mass exodus to ROR. PHP could wind up being relegated to individual scripts or 5 page websites.

  21. Re:Backgrounds of the PHP developers. by trifakir · · Score: 2, Insightful
    I disagree. Plenty of software in general, and some languages in particular suffer from the "too much design" disease. On the other hand, software which is being written well (for some definition of "well"), tends to outgrow the flaws in its initial versions even if at the end one can hardly recognize that this is the same software.

    The classical example of an "overdesigned" language is Java (I am lousy at separating the language from its APIs). What you get is some more "reuse" at the price of unnecessarily complicated framework. With languages like PHP you learn the right way by mistake (which is not necessarily suboptimal) and you should have the guts to break compatibility from time to time.

    As for being disgusted by PHP -- usually you don't get disgusted by the language but by what people have written in it (or around it - talking about some PHP extensions). One can always find examples of an extremely ugly LISP function with LISP being one of the most beautiful languages ever.

    But I'm heading towards a treacherous field - discussing programming language merits - wasn't it "the best tool for the appropriate job"? So, let's keep PHP for all these "gee whiz" tasks which apparently the society needs, otherwise go explain the x millions of PHP-sites...

    At the end we will all grow software like plants :)

  22. Flamebait my ass, this is true. by Some+Random+Username · · Score: 2, Funny

    Mod the poor guy back up, PHP's mail() function is completely retarded. I have never seen a single PHP contact form that isn't exploitable to send spam because of this nonsense.

  23. PHP5 deserves any criticism it gets by tehshen · · Score: 2, Insightful

    Since when has the "If you don't use it, stop complaining" attitude been acceptable? I don't use Windows, but I'm constantly pointing out its faults to people so they're less likely to get infected and have their computer send out spam. I don't smoke, but I'd rather point out the dangers of smoking to someone than let them cut ten years off their life.

    A while ago, I tried writing my own blogging system using PHP, because it would be easy to find someone to host me. I kept having to look things up (isnull or is_null? arrlen or array_length? (neither, it's count)), typing mysql_this, mysql_that instead of using namespaces is annoying, lack of a good scoping system very annoying, etc etc. I did want to use PHP, but didn't, because I thought it sucks. Would you prefer it if I didn't say anything, and just let the PHP guys carry on with the mess they've made? Hint: that wouldn't accomplish anything.

    "PHP is the web generations basic". Oh great, the web generation is growing up thinking that mysql_query( $_POST['input']) is a good idea. After all, magic quotes will make sure it's safe, so gets(input); system(input); in C should be safe! Intentionally or not, PHP is the first language learned by many people nowadays, so it should at least educate them into good practices instead of just doing stuff for them. (Doing things for the user is one of the things that Microsoft gets flak from here, too). PHP tried this before, with register_globals, and look what that turned out to be.

    Surprisingly, people actually want to make PHP a better language, but apparently any complaints should be met with "Don't like it? Then get lost!", leaving PHP as it is. Oh well.

    --
    Guy asked me for a quarter for a cup of coffee. So I bit him.
    1. Re:PHP5 deserves any criticism it gets by Anonymous Coward · · Score: 2, Informative

      Since when has the "If you don't use it, stop complaining" attitude been acceptable?

      Usually thats a scape goat for a lot of people, but in all honesty they are almost forced to use it because their are just some people that won't get off their backs. It's like when a little kid asks "why?" too much, an educated parent would simply say "because I said so."

      A while ago, I tried writing my own blogging system using PHP, because it would be easy to find someone to host me. I kept having to look things up (isnull or is_null? arrlen or array_length? (neither, it's count)), typing mysql_this, mysql_that instead of using namespaces is annoying

      Namespaces would be nice, but I honestly don't see whats so bad about the current system. I've written some very nice projects without using namespaces at all, and guess what, entire operating systems have been built without namespaces! Also, your inablity to memorize function names is not the fault of the language. You are obviously trying to turn php into something its not by suggesting that ABC naming system is not as good as XYZ naming system. Don't blame the language just because it does functions a little differently. It's part of learning the language. The more you use them, the better you'll know them and the more natural it will seem. Just try not to force that natural state you've come to acquire into another environment when learning a new language.

      "PHP is the web generations basic". Oh great, the web generation is growing up thinking that mysql_query( $_POST['input']) is a good idea. After all, magic quotes will make sure it's safe, so gets(input); system(input); in C should be safe!

      No one ever said magic quotes would make these things safe. NO ONE! This paticular quote of yours is 100% plain and simple a lack of knowledge. Php has a wealth of functions that will strip slashes and quotes and html elements to make input safe. In the end though, its up to the developer to make sure the input is safe. Your little examples are totally pointless. You could write any variation of that system(input); example in ANY language! You seem to think because php is a web language that its exempt from this. Well it's not! Any developer in their right mind knows mysql_query(input); is insecure... but again, how in the world do you think thats the fault of the language???

      Intentionally or not, PHP is the first language learned by many people nowadays, so it should at least educate them into good practices instead of just doing stuff for them. (Doing things for the user is one of the things that Microsoft gets flak from here, too).

      three letters... wtf?! PHP does a fine job of educating people on good practices. If some noob comes along and copies and pastes crap code from a tutorial site on geocities whose fault is that? The developer's or the languages? That's like blaming Toyota because some jerk is a bad driver. The thing that really dropped my jaw on your statement is the part about php "just doing stuff for them". What are you talking about! What is it that php does for them? Provide commonly used functions to make development easier? Thats "doing stuff for them"???? It's pretty clear you've never programmed using Microsoft technologies or in php. The reason MS got so much shit was because their IDE messed with people's code with their autocomplete feature. On top of that, it is VASTLY improved now. Have you ever used VS.NET 2005? Hell I bet not. You're still living in the 90s. I bet after a long hard day of posting non-sense to /. you head over to Sun's website and post "Java is slow" all over their message boards. You have no real world expierence with this kind of stuff and base your entire opinion on some goof-ball posted on a message board. Please... LEARN php and learn it well before stouting your uneducated opinion. And don't bring up MS references if you have no idea where they come from. Please, do some research.

  24. Re:Backgrounds of the PHP developers. by dragonman97 · · Score: 3, Informative

    Unlike some of the other replies, I agree wholeheartedly. I am a Perl programmer, who actually has a clue about programming. (And I write legible Perl, thank you very much. [most of the time ;)])

    I've just 'inherited' a PHP project, and I want to scream. I've finally had to 'learn my enemy.' So, wanting to know what the heck I was getting into, I bought a ton of O'Reilly books, and I read through a bunch of "Programming PHP" before beginning, so I wouldn't make the mistake of just slapping together whatever worked. Getting right into it, I was appalled at how poor the 'design' of the language is. It's a poor ripoff of many decent languages, slapped together in whatever Q&D way would 'make it work.' Why are phonetic string comparison functions part of the core language?! Those should be in a library! Why, oh why, was the scoping done so utterly backwards?! I was cleaning up some code, moving it into a function, and suddenly it stopped working. I had realized the answer the first time I tweaked it, but summarily forgot the second time around. What was it? Why, naturally, I had forgotten to do 'global $foo' inside my function - how stupid could I be to think code inside a function wouldn't pick up the contents of the variable as declared outside it?

    *sigh* I've gotten a project with 15,600 lines of 'code,' and already gotten rid of 1200 lines of repetitive junk by applying some common sense to it. I have another 120 lines lined up to be shot today. (A diff -uw of 2 files turned up exactly 5 differences.)

    PHP makes it way to easy for people without a clue to 'write code' that 'works.' Thank you all the same, but I prefer to keep my brain engaged in 'drive,' rather than 'park.'

  25. Never Program- RFC822, workarounds by PhYrE2k2 · · Score: 2, Interesting

    You sir, should never program.

    Always validate all input provided by the user that is used in any way. If it's in a database you're smart enough to escape it (or use query replacement methods that do it for you). If you're sending mail, you damn-well be sure it's an e-mail address. You have RFCs to guide you on this:

    http://www.w3.org/Protocols/rfc822/
          A field-name consists of one or more printable characters (excluding colon, space, and control-characters). A field-name MUST be contained on one line. Upper and lower case are not dis-tinguished when comparing field-names.

    It defines what characters are valid, and if you are about to pipe whatever data you accept into an e-mail, that's something YOU decided to do.

    IT IS YOUR JOB to make sure that what you put beside FROM: (or anything in that parameter) is an e-mail address. It shouldn't have a newline. It shouldn't have escape characters. It should probably contain only a limited regex. Would you put an SQL query someone enters into a database? Then why an e-mail address to sendmail?

    On a side note, the only way around this is to have a programming language that tags data as tainted if it came from or was derrived from user input and not allow it for input, and having functions that sanitize data and remove that flag. This is first off slower and second not optimal in many situations.

    --

    when you see the word 'Linux', drink!
  26. A work in progress... PHP is getting better by PhYrE2k2 · · Score: 2, Insightful

    PHP is getting considerably better actually at being (a) a mess, and (b) making you learn by mistake, (c) providing simpler frameworks.

    This is what PHP 5 and PHP 5.1 are all about. Lets fix the problems in the language and those things that go back to it's origins. PHP at one point did little more than a shell script, and now you have endless numbers of modules, extensions, and database backends.

    You'll notice they have E_ALL on by default and highly encourage E_ALL|E_STRICT to be used for good coding practice. You'll notice register_globals is off by default. You'll notice countless quirks are virtually eliminated. magic_quotes are off by default because it's become apparent they don't always work and it's better done by the database engine (which can escape what it needs rather than just slashing random things).

    You'll notice in 5.0 and 5.1, they pulled out extensions that are specific or not maintained (payflowpro, fileinfo, and many others) to PECL.

    You'll notice they are recommending mysql extensions and others aren't use. You'll notice they're even advising that mysqli isn't used. You'll notice they are focusing on PDO to simplify and eliminate the ~10 driving extensions for each database engine with their own unique ways of doing everything with a universal framework (note: PEAR::DB is written in php classes- this is C and good code).

    This is all a method to fix those problems everyone keeps complaining about. It's a pain, and creating even more complaints in the process of broken scripts, classes, and tools with the removal of things like is_a, call-time reference passing, and others- but once these scripts get fixed, and over time once everything goes PDO--- You'll find clean and swift code without much trouble at all.

    Give it 6mo for the whole php 5.1 thing to migrate into various popular scripts and you'll find the world will be better for it. It's all in the master plan- simplify. Note that while many things have manual sections, much of it is in PECL and not the distro. At some point that should really be pulled into its own manual making it easier to find the core topics. That's just my opininion.

    -M

    --

    when you see the word 'Linux', drink!
  27. Re:You forgot one. by jZnat · · Score: 2, Interesting

    Oh boy, I can account for this claim completely. I used to co-program with another person on a large website that used MySQL from the start. Him and myself would constantly look for ways of increasing performance and minimising lag, but we never tried using a different database. With a site that massive at the time, we should've been using PostgreSQL at least, or even Oracle or DB2 or similar if we could get the money to buy it. I even went as far as rewriting the entire system with the most optimised PHP code possible, and we minimised database usage and dependence, moving several things to sessions that would occasionally update from the database. We even used partitioning strategies by placing the main culprit of the data usage, the forum's replies table (nothing would get purged, only archived with an archived bit set to 1), on a separate hard drive that was only used for storing backups of the database. Performance shot up for a few days, but it quickly went back to sucking ass.

    Sure, with all that, I've come to learn how to exploit MySQL to get its best performance, and how to use PHP to its maximum performance, but we would've been better off using a transactional database for one, and more specifically if we had used PostgreSQL from the start. Those efforts are primarily available here, but since the inital optimisations, I've transferred everything to use ADOdb Lite. I hope to get this transferred to a PostgreSQL database instead, but it won't matter much for the original site in question as I no longer program with him.

    --
    'Yes, firefox is indeed greater than women. Can women block pops up for you? No. Can Firefox show you naked women? Yes.'
  28. Re:PHP alternatives by iluvcapra · · Score: 2, Informative

    When you hear Ruby in the context of web applications, the speaker definitely means Ruby on Rails. For writing more than the simplest web application, it's probably a php killer, on account of its price ($0) and relatively flat learning curve (even if you've never done ruby). Others have observed that RoR has subtle ways of making you do the right thing in a given programming situation, even if you don't know what that is at the time. I dare say that rails teaches the coder alot about object-oriented programming just by using it.

    RoR is just 1.0 now, and though the API is still shifting around a bit, it does so only about as much as php, and rails is just a framework, not the whole language. The ruby language itself is quite stable at this point. OTOH, I found that porting my existing web app over to RoR was impossible, or at least so difficult that it wasn't worth the trouble over re-coding it from scratch (and making it a much better app in the process).

    --
    Don't blame me, I voted for Baltar.
  29. Re:Backgrounds of the PHP developers. by killjoe · · Score: 3, Insightful

    Personally I think the use of the "global" keyword is something PHP got right and every other language (except ruby) got wrong. When you are reading a function it's good to know where all the variables are coming from. In ruby they use a sigil, in PHP they use a keyword, in every other language you have to search through the function to see where and if the variable was declared and deduce that it was either a global variable or a typo.

    To recap. PHP got it right, perl got it wrong. You are annoyed because it's not the way you are used to working but that has nothing to do with the merits of the scoping rules.

    --
    evil is as evil does
  30. Who to emulate today? Perl? Java? C++? by theolein · · Score: 2, Interesting

    I started off doing web coding in PHP 3 years ago, and was even pleasantly pleased when PHP 4 came out as it was a real, practical improvement over PHP3, especially as regards sessions and form data. Since then, I've learnt Java, ASP, Perl and Cold Fusion and started on Ruby. (and C/ObjC for native development)

    Today, after not having done any PHP for about two years, I took a look at the PHP 5 documentation.

    I was appalled.

    Back when I started learning Perl, many of the apparent idiosyncrasies in PHP made sense such as the $syntax, multiple variable assignation, string concatenation and others. PHP had made a simpler version of Perl (automatic dereferencing, yay!). Then, when I was reading through the docs I noticed that PHP5 was doing its utter best to ape the functionality of Java (OO, exceptions, collections, interfaces, reflection, overloading, overriding etc) with the syntax of C++ (:: for static members, -> for virtual methods) but with the same loosely typed variables (Just ask yourself when looking at code you've never seen exactly what type does that unknown function return) and no namespaces (Perl, Java and C++ all have this in some form or another) and a huge array of functions that has no consistency whatsoever.

    So, in essence, we have a language that is a mix of Perl, Java and C++ but with no real innovation of its own, unlike Python or Ruby, both of which are extremely consistent and remain true to themselves. Even lowly Javascript is far more consistent than PHP.

    There is no way that I will code or design a large webapp in PHP. I had to debug a fairly complex one recently and it was a nightmare. I think I'll wait another few years and look what PHP6 turns out to be.