Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
PHP Programming

A Decade of PHP 452

Posted by Zonk from the i'll-bring-the-cake dept.
digidave writes "It was slow to catch and a lot of people didn't get it. A lot of people still don't get it, but you can't argue with its success. June 8th, 2005 marks the tenth anniversary of PHP. Here's to ten more wonderful and exciting years."
This discussion has been archived. No new comments can be posted.

A Decade of PHP More

A Decade of PHP

Comments Filter:

  • Congratulations are in order! (Score:4, Insightful)

    by AKAImBatman ( 238306 ) * <akaimbatman AT gmail DOT com> on Thursday June 09, 2005 @10:18AM (#12768485) Homepage Journal
    Congrats to the PHP development team! PHP has long followed the KISS principle while still maintaining the Unix APIs that we've all learned to know and love. While it's not the best web scripting platform for all purposes, it is a free and flexible alternative for many, many dynamic webpage projects. It's only because of PHP that so many OSS web applications have been allowed to exist.

    It was slow to catch and a lot of people didn't get it.

    Ok, I'm with the slow-to-catch-on part, but what's this about people not getting it? The concept had to be one of the simplest ever designed. (Thus the reason why it's so common across web scripting languages.) Here is your HTML, here's a bit of Unix scripting langauge. Simple, see? :-)

    On a slightly different topic, one wishlist item that I would like to see in PHP is Abstract Database Access. It's not really a good thing to hard code your application to a specific database, especially if it's a redistributable application. (e.g. PHPBB) The ODBC calls sort of solve this, but they do require that ODBC is installed, properly configured, and compiled into your copy of PHP. (Does anyone know if any distros now have ODBC as a "standard" library?) This assumption can't be made for most OSS applications, so they tend to tell you to just use MySQL.

    • Re:Congratulations are in order! (Score:5, Informative)

      by quinto2000 ( 211211 ) on Thursday June 09, 2005 @10:21AM (#12768509) Homepage Journal
      there are several classes, including the PEAR DB class, that provide a DB abstraction layer.
    • On a slightly different topic, one wishlist item that I would like to see in PHP is Abstract Database Access.

      Actually, what I'd like to see is bitwise-operations on strings - my Ogg Vorbis decoder written in PHP is currently languishing at just a bare-bones Ogg demuxer 'cos unpacking all the Vorbis packets proved just too fiddly...

      • You wrote an OGG Vorbis decoder in PHP? Maybe I'm missing something, but why? That doesn't strike me as a very good language to be doing such a thing in. The "PHP Way" is to leave heavy processing like that to an external library such as libogg/libvorbis. You can then use PHP as a frontend for presenting info, streaming the data, and uploading files.

        I realize that PHP can be cool at times, but one has to use the right tool for the job at hand. :-)
        • I realize that PHP can be cool at times, but one has to use the right tool for the job at hand. :-)

          That was precisely the reason I chose PHP - because it was absolutely the wrong tool for the job.

          Well, maybe not quite as bad as some. Anyone want a port to Javascript? BBC Basic? Befunge? ;-)
    • It's not really a good thing to hard code your application to a specific database

      For most simple apps (90% of what PHP apps are) you should stick with SQL-92 syntax when you write your queries. Then just write yourself some generic functions that you pass your query and a connection string to. The functions determine the db-specific query execution code to use. I always use parameterized queries. So I've even got functions to switch the parameter character ('?' or '@' etc) to the syntax of the target db.
      • I completely agree. The primary reason why native code would be nice is that a bundled API would help put peer pressure on coders to use it. Which means that we'd see fewer "quick hacks/prototypes" (that always turn into production sites) using database specific code.
      • There are reasons for database-specific code: not all databases are the same.

        The "lowest common denominator" data storage/retrieval does not actually mean you can use your database like a Relational Database Management System.

        If you don't want your database to do what Relational Database Management Systems do, and you're just going to use it for flatfile-like queries, why not just use SQL-Lite? SQL-Lite has familiar syntax, but can be bundled with the application. You don't have to worry about what databa

    • Re:Congratulations are in order! (Score:5, Interesting)

      by rho ( 6063 ) on Thursday June 09, 2005 @10:33AM (#12768678) Journal
      I've never understood the fanaticism of database abstraction. There's good reason to hardcode to a specific database, especially if you hardcode to a Free database like PostgreSQL.

      For example, if you use a database abstraction, you have to make a lot of performace- or feature-robbing choices. There are still hosting situations where MySQL is still on 3.23, so you can't use the better parts of the InnoDB storage engine. So no foreign key constraints, no stored procedures.

      On the other hand, if you do hardcode for PostgreSQL, you put a burden on the end user, sure--but in return, you're giving them a more robust, more featureful application that is easier to support and maintain. I personally like PostgreSQL because it seems less haphazard than MySQL, but you could very easily do this with MySQL, so long as you restrict yourself to the later, non-crippled versions.

      The Arsdigita folks did this with Oracle. Leaning on a $tens-of-thousands database application may put you out of the realm of everyday developers, but it's far from insane.

      This is "all the time I've spent dealing with other people's code that doesn't have a foreign key to be found and all integrity checking is done in the PHP code" talking. It's infuriating.

      • You can easily code your SQL to be database specific if you need it that way, but that shouldn't in any way stop developers from using a generic DB access API. A DB abstraction is nothing more than a mapping of functions, so there's rarely any performance hits. Which means that applications that don't need a specific database (e.g. PHPBB anyone?) could be portable out of the gate. And even if their SQL isn't portable, that's a far easier thing to fix than attempting to add a DB abstraction after the fact.

        • Not so good an idea (Score:4, Insightful)

          by soloport ( 312487 ) on Thursday June 09, 2005 @11:57AM (#12769743) Homepage
          Database abstraction is a frustration of mine.

          Say, for example a "real" DBA writes a shopping cart schema / application, using a "genuine" (ACID-compliant) DB, the scalability will be phenomenal; The speed will be incredible because much of the code will be handed TO the database -- not parsed and parsed and parsed away at the PHP/Java/whatever-script level.

          Now, let's say a "wannabe" DBA writes a shopping cart schema / application using MySQL. Then to "help" the Postgres folks out, the DBA adds an abstration layer. Woo hoo!!! Useless... Essentially, I'm offered a way to drive a Ferari (Postgres) down the sidewalk, negotiating with pedestrians all day, as if I were traveling by skateboard (MySQL).

          Unfortunately, the number of examples of the later are a dime a dozen. The number of examples of the former are near zero. Think about why you'd even WANT abstraction. In most real-world cases it's rather useless and undesireable.

      • Database independence (Score:3, Insightful)

        by 3770 ( 560838 )
        I support the idea of database independence.

        But it should be done by using standard SQL.

        Unfortunately, that is not a losing battle, it is a lost battle.

        The database vendors doesn't care about standard SQL.

        • Some do, some don't. It's now possible to write 100% ANSI compliant systems in Oracle and MS-SQL amongst others (those are the two I know of for sure, I also know there are others). Obviously you can choose to use non-ANSI compliant code if you so wish. Sometimes there are good reasons to do so, using supplied packages to perform tasks that would otherwise have to be coded is one. As noted earlier, writing your code to fit a particular RDBMS will often result in faster code. It may also give you a fas

          • Re:Database independence (Score:3, Informative)

            by 3770 ( 560838 )
            Here is a good comparison that I use:

            http://developer.mimer.com/validator/comparison/up d_comparison_chart.tml [mimer.com]

            • Looks interesting. It doesn't appear to be 100% accurate though. There are a number of features (e.g. E051-08, E021-06 and E021-04) that it says that Oracle 9 does not have but I know it does, or at least it has something matching the description given (maybe I'm misunderstanding something).

              Stephen

              • Re:Database independence (Score:3, Informative)

                by 3770 ( 560838 )
                I think that the chart is rather accurate. I know the people that made it and one of them is in the SQL Standards committee (Åke Persson).

                It may be really picky and unforgiving, however, and even a minor deviation from the standard might disqualify a feature from being listed as supported for a certain database. I can't say that that isn't the case. All I'm saying is that they guys that made the list know what they are talking about.

                Åke Persson is also a compiler expert and he wrote this tool:
      • Hear here!

        I've never understood the fanaticism of database abstraction. There's good reason to hardcode to a specific database, especially if you hardcode to a Free database like PostgreSQL.

        You took the words right outta my mouth. I tend to work on large projects, usually the app has its own server (or servers) to work on.

        I've hard-coded to Postgres since 7.0 came out, and I've NEVER regretted it. The only problem I've had is when one of my clients demanded "cross-platform".

        I had more problems with th

    • PHP definitely does not follow the KISS principle (Score:5, Informative)

      by Peter Cooper ( 660482 ) on Thursday June 09, 2005 @10:33AM (#12768679) Homepage Journal
      PHP has long followed the KISS principle

      Are you smoking crack? PHP is more inconsistent than any other language I've encountered. I'm not disrespecting the team, as I'm sure they've worked hard, and it's great to celebrate ten years of an admittedly very useful language, but PHP is not an inherently easy language.. it's just one that lets you code sloppily and get away with it.

      For a start, PHP functions seem to have no consistency at all. Sometimes you get verb/object, sometimes object/verb. Sometimes you get underscores, sometimes you don't. Consider.. is_object but isset. str_rot13 but strpos. php_uname but phpversion. There are hundreds of these. It's the reason I could never learn PHP, it's like learning Chinese, but I found Perl (and now Ruby) easy due to their relative consistency. Sometimes PHP uses "to", sometimes it uses "2".. huh what's that about?

      Unlike Perl which has a few regular expression constructions and a handful of modifiers.. PHP has a whole glut of regular expression functions which have confusing names, some of which take certain modifiers, and some that don't. As someone who has mastered Perl's regular expressions I find it a major struggle when I have to tackle something in PHP (I admit, I've never 'learned' PHP, but I find it a very hard language to make quick fixes on for other people.. compared to, say, C, VB or Python, languages I don't know intimately but can easily hack).

      PHP has thousands of core functions.. nuts! And why does PHP have such a bizarre lack of abstraction? PHP often has about 10 functions compared to other languages' single function.. with each of the 10 doing a slightly different thing. When it comes to being overly wordy and inconsistent, I doubt anything can beat PHP, but, well, I'd like to see someone bring up a language that is!

      So if you were going to call any language "KISS", it'd be Ruby or Python.. but PHP? No way.
      • Are you smoking crack? PHP is more inconsistent than any other language I've encountered.

        Nope, I'm just a realist. PHP was designed to be a web scripting language that wrapped Unix APIs. Nothing more, nothing less. I in no way agree with the fanaticism surrounding PHP (it doesn't make a good general purpose language people!), but it does what it was designed for in a straightforward, simplistic fashion. I usually prefer to do things in JSP/Java, but if it's not an option for some reason then I prefer to u
        • Aha, I was looking for a worse language than PHP and I think we've found it. ColdFusion! How could I forget about that nugget of programming fools' gold ;-)

          I would agree that PHP makes a decent web scripting language for basic tasks (polls, counter, guest book, a bit of remote inclusion), but I am horrified to see people actually using it for serious stuff like enterprise level systems. That sort of stuff makes the blood freeze. I feel really sorry for the corporations who get sucked into it.
          • But on the toher hand, PHP isn't really ciplled in any way, is it? Sure the function names are varying, but that can be fixed eventually. It's just easy to do things right there on the spot, instead of doing it really elegantly, but if you force yourself to do things the right way, wouldn't PHP be as good as any other option?
        • Well, your anecdote of 2 ColdFusion sites that crashed doesn't really prove much.

          I've been working with ColdFusion for about 5 years now. My sites don't crash- and I get 10-20 million hits per month. Not huge, but a pretty good number. (No...this is not the site that is in my sig...)

          I *might* get 2 or 3 'unhandled exceptions' in a day. And those are always caused by search engines that are hitting templates with bad queries. It is interesting to see the queries they send, "hmm...why did they decide t
      • I agree with the simple inconsistencies. What annoyts -- no, frustrates -- me most is that the functions that have a string and an array for an argument is that sometimes the array comes first, and sometimes the other argument comes first. I hate it.

      • Re:PHP definitely does not follow the KISS princip (Score:5, Informative)

        by bobdinkel ( 530885 ) on Thursday June 09, 2005 @11:09AM (#12769152)
        As someone who has mastered Perl's regular expressions I find it a major struggle when I have to tackle something in PHP (I admit, I've never 'learned' PHP, but I find it a very hard language to make quick fixes on for other people.. compared to, say, C, VB or Python, languages I don't know intimately but can easily hack).

        Just a quick point--you can use Perl's regular expressions in PHP. And that's usually what I see people doing. As a matter of fact, it is recommended in the PHP documentation that Perl's regular expressions be used: Note: preg_match(), which uses a Perl-compatible regular expression syntax, is often a faster alternative to ereg().

      • Re:PHP definitely does not follow the KISS princip (Score:4, Insightful)

        by killjoe ( 766577 ) on Thursday June 09, 2005 @11:10AM (#12769163)
        Lucky for you there is a centralized, annotated, comprehensive, searchable, accessable by web services manual and a centralized repository of standard classes.

        People underestimate the power of those two things. CPAN is the number one reason why PERL is still so popular.

      • Re:PHP definitely does not follow the KISS princip (Score:4, Insightful)

        by julesh ( 229690 ) on Thursday June 09, 2005 @02:07PM (#12771559)
        For a start, PHP functions seem to have no consistency at all. Sometimes you get verb/object, sometimes object/verb. Sometimes you get underscores, sometimes you don't. Consider.. is_object but isset. str_rot13 but strpos. php_uname but phpversion. There are hundreds of these. It's the reason I could never learn PHP, it's like learning Chinese, but I found Perl (and now Ruby) easy due to their relative consistency. Sometimes PHP uses "to", sometimes it uses "2".. huh what's that about?

        Most of the functions in the PHP distribution are named after a function that does the same thing in the C library that PHP uses to implement the feature. PHP is designed so that if you're familiar with the C library that it is using, you can very easily get the hang of the PHP version.

        This doesn't excuse some of the weirdnesses in the core library, though -- str_rot13 (and the other string functions with underscores in them) is clearly wrong, as the earliest string functions followed the standard C library naming conventions.

        To address your other examples: isset() is an operator that looks syntactically like a function, and would have been named in this fashion to mirror the other such operators (sizeof(), unset()). is_object() et al are functions that were implemented independently of this, and at the time there was no conflict. I see no excuse for the php_uname/phpversion difference.

        PHP has thousands of core functions.. nuts! And why does PHP have such a bizarre lack of abstraction? PHP often has about 10 functions compared to other languages' single function.. with each of the 10 doing a slightly different thing. When it comes to being overly wordy and inconsistent, I doubt anything can beat PHP, but, well, I'd like to see someone bring up a language that is!

        I don't like to nitpick, but... those aren't all core functions. They're just functions that are distributed with the core, kind of like the applications that come with a Linux distribution. You can build a stripped down PHP without them, if you want.

    • Hear! Hear! Thx Rasmus. I still remember one of my co-workers first encouraging me to use PHP for CGI scripting about 5 years ago, and me saying "Nah, Perl works a-ok for me." Well I also used the Bourne Shell for CGI scripting once upon a time too and moved along.

      PHP really is the right tool for the job of building websites. It was designed with that in mind, so that's not a slam against Perl in any way.

      To be fair, I should really check out Python and Ruby soon... The great thing about PHP now is that

    • In 1999 when I first started gathering talent for a web hosting company (in lieu of a PHP position, which I found a month later), I met set a meeting with a programmer named...John in a San Jose Embassy Suites. Upon hearing, the important detail; we would be using PHP in lieu of Perl, he promptly called me crazy and informed me he wouldn't be wasting his time considering working with someone who was trying to use PHP(PHP/FI at the time). Nice not working with ya John.
    • If you think that "PHP" and "KISS" [php.net] belong in the same sentence (without a negation operator), then you're nuts. Having separate functions (in the main namespace, no less!) for every possible way you might want to sort a list is not simple, reasonable, or the standard accepted way of doing such things.

      When you can explain the core language and primary namespace to an interested programmer in under 30 minutes, I'll be glad to revisit the topic. Until then, Python is simple. Perl is even reasonable simple. PHP is not simple in any way, shape, or form (unless you're using the facetious Simple from SMTP, SNMP, and other horridly complex standards).

  • What's not to get? (Score:3, Insightful)

    by Enigma_Man ( 756516 ) on Thursday June 09, 2005 @10:19AM (#12768492) Homepage
    Seriously, honest question. What's not to get about a language? It's just another language with different options, styles, formats, and uses...

    -Jesse

  • Good for them. (Score:4, Funny)

    by Willy on Wheels ( 889645 ) on Thursday June 09, 2005 @10:20AM (#12768507) Homepage Journal
    I have been an avid user of php, I have even made my own website using PHP. It is so good that big sites such as mine use it. For all serious developers, PHP is the best choice for all php programming.

  • I don't really like PHP that much... (Score:3, Insightful)

    by Anonymous Coward on Thursday June 09, 2005 @10:21AM (#12768527)
    What is so exciting about it? I can't find a single situation where it is better to use PHP than other programming languages. Why would anyone love PHP?
    • It's not "exciting" but PHP is one of those languages that's successful and useful because of its marketing and "who knows who". You won't find many hosting companies that won't allow PHP scripts to be run on their servers.. whereas better languages like Python, Ruby, etc.. all have rather bad support with ISPs. The start of the problem is that most ISPs won't support FastCGI, and that's the primary way these other languages should be deployed on servers nowadays.

    • PHP is good because it's easy. It might often not be the most sophisticated, structured, or easily maintained language, but it is often the quickest and simplest solution to a problem. In that respect it fills an important niche.

    • Try this:

      What is so exciting about it? I can't find a single situation where it is better to use [Language X] than other programming languages. Why would anyone love [Language X]?

      Every language has both strong and weak points. PHP is extremely easy to learn and works great for both web programming and simple command-line purposes. That is unless you are just trolling. (Why does PHP hate the internet?)

  • Congratulations PHP (Score:5, Funny)

    by GnuVince ( 623231 ) on Thursday June 09, 2005 @10:23AM (#12768552)
    You've done such a wonderful job that it's time you stop now and let something better [rubyonrails.org] take over :)
    • Yep, but it'll take another 10 years before the peons get it.
    • Yeah, this sounds like what the PHP folks were saying about Perl something like 6 years ago. I know you were tongue in cheek, but really--isn't language bigotry a pretty old joke by now? Perl is still around; PHP will still be around; and Ruby-on-rails will still be around when SexCodeSuperFunNerds arrives to "displace" it.

      • Re:Congratulations PHP (Score:5, Insightful)

        by Black Perl ( 12686 ) on Thursday June 09, 2005 @11:06AM (#12769117)
        isn't language bigotry a pretty old joke by now

        You're one of those people who don't get it. This is not a language issue. In the not-so-distant future, developers will think it crazy not to use an MVC web framework for their web applications.

        Ruby on Rails just happens to be first with an elegant, easy-to-use, true-separation-of-concerns, MVC web application platform.

        The Java, Python, and Perl (Catalyst) folks have seen the light and are busy working on Rails-style frameworks. Seems like the PHP community hasn't seen the need yet.

        • Re:Congratulations PHP (Score:4, Insightful)

          by rho ( 6063 ) on Thursday June 09, 2005 @12:44PM (#12770317) Journal
          n the not-so-distant future, developers will think it crazy not to use an MVC web framework for their web applications.

          You know, I heard the same thing about Java back in 1996 or so.

          Don't get me wrong, Rails looks decent enough, but neither is it a panacea. You can put together a really fast RSS reader, or a DB-backed recipe application, but these are trivial applications. Solving trivial problems elegantly isn't worthless, but thus far I haven't seen any Rails projects that compare in scope to something like Zope, or Drupal or even PHPBB.

          Going through the various How-Tos for Rails, I keep saying to myself, "...or, I could just download foo, which is written in Perl/PHP/Python/AWK, but already works and is proven and does the same thing." PHP hasn't seen the need for copying Rails because they have a robust and featureful set of applications already. Dropping everything and chasing the next sexy thing might be entertaining, but it doesn't do much to help me, the working Webmaster.

          I guess I'm just suspicious of using MVC (or OOP, or some other trendy buzzword) as a talisman. It smacks of cheerleading, and accusing people of "not getting it" doesn't prove the point.

  • PHP vs JSP (Score:5, Interesting)

    by SamSeaborn ( 724276 ) on Thursday June 09, 2005 @10:23AM (#12768557)
    Congrats to PHP for its success, but I'm one of those who doesn't get it.

    I tried PHP, but I didn't feel it gave me the rigid OO structure and sophisticated APIs I get from Java, JSPs & Servlets.

    Not trolling, just saying I'm surprised that Java and Servlet hosting isn't as popular as PHP. I'm obviously missing some key point.

    Sam

    • Re:PHP vs JSP (Score:5, Insightful)

      by Frymaster ( 171343 ) on Thursday June 09, 2005 @10:29AM (#12768624) Homepage Journal
      I tried PHP, but I didn't feel it gave me the rigid OO structure and sophisticated APIs I get from Java, JSPs & Servlets.

      but procedural is a valid way to structure your apps... especially for web-based ones where that have, by nature, a page-based model and a very linear flow. you can write serious software using php4 without oop!

      • Re:PHP vs JSP (Score:5, Insightful)

        by ajs ( 35943 ) <ajs.ajs@com> on Thursday June 09, 2005 @11:14AM (#12769216) Homepage Journal
        quoth Frymaster, "procedural is a valid way to structure your apps... especially for web-based ones where that have, by nature, a page-based model"

        This is my basic gripe with PHP. It leads the unfortunate user down a path that suggests that each page is its own island, and any attempt to modularize or componentize that is, by PHP's nature, a secondary affair.

        Take, as a counterpoint, something like TTK. Here, you are presented with a programming langauge in which you write your code, and a templating system in which you write pages for display and a set of tools for connecting the two.

        It's not that a good programmer can't produce a workable system in PHP alone or PHP + other langauges (PHP backed by Perl or Java or C# is quite powerful, in fact), it's just that it seems that the majority of people writing PHP are hobbled by this unfortunate presentation of the language as a "page generator", and thus most of the code written in PHP is rewrite-fodder from day one.

        As a templating system, PHP is quite nice, and I'd use it where appropriate.

    • Re:PHP vs JSP (Score:5, Insightful)

      by NardofDoom ( 821951 ) on Thursday June 09, 2005 @10:31AM (#12768650)
      The key point you're missing is that PHP doesn't have a rigid OO structure, which is why it's popular, especially for web scripting. People don't want rigid structures if they just want to throw a page together. It also is integrated well with Apache and uses similar control functions to C/C++, so programmers can switch between the languages easily.

      • Re:PHP vs JSP (Score:3, Insightful)

        by Neil Watson ( 60859 )
        The lack of rigid structure and thowing a page together are the very things make PHP a potentially dangerous language. When in the right hands PHP is a good tool. However, it does allow for sloppy work.

    • Re:PHP vs JSP (Score:3, Informative)

      by xannik ( 534808 )
      I think the main reason is that OO is just not important when writing simple scripts that are taking information say from an HTML form and inputting into a database or some other simple yet highly used task. Most people that are using PHP on a shared hosting provider will probably not need to use any OO features. Now, the PEAR project for PHP does provide good abstraction for the language and I think makes PHP a much more usable system for higher end projects. I guess what I am trying to say is that for
    • As others have noted, you don't always need OOP. That OO exists is not a requirement that one uses it to solve every problem presented. Handling input from an HTML form and storing it to a database doesn't really need OO, does it?
    • Back in the days, say a few years ago at least, getting JSP and Servlets up and running was a pain, even if you knew and used Java already, and had it installed. And then it was a pain configuring it all. PHP, as I remember it, has always just worked, with ease. No, I don't know how the status is today, and since I don't miss Java I don't need to know. Back then this was important though.

      After all that was done, well then it was up to if you liked Java or not. And I've come to realize that Java is a langua
    • I tried PHP, but I didn't feel it gave me the rigid OO structure and sophisticated APIs I get from Java, JSPs & Servlets.

      The answer is: Two completely different markets.

      JSP requires a minimum investment in hardware, resources, and server capabilities that PHP does not. JSP also tends to require more backend APIs than PHP, because you try to keep as much out of the JSP as possible. As a result, JSP tends to be the best solution for Mid to Enterprise class systems, while PHP makes a good choice for Per
    • What do you mean by "rigid OO structure"? The OO in PHP is not all that different then Python (although it's missing some of the functional programming aspects of python.
    • I'm surprised that Java and Servlet hosting isn't as popular as PHP

      The main reason, IMHO, is that PHP is much more easy to install on a typical Apache web server, and much more appropriate for mutualized hosting.

      With PHP (as a module or CGI), once a HTTP request is finished, all the resources (memory, DB connections, file handles, etc.) are given back to the operating system. With Java, the JVM keeps running after a request, and might keep locks on resources without anyone noticing.

      This is a key ad

  • Thanks for the career, PHP!! (Score:5, Insightful)

    by ylikone ( 589264 ) on Thursday June 09, 2005 @10:25AM (#12768586) Homepage
    I've made my living for the past 3 years as an independent PHP developer. I don't care what anybody thinks of PHP, it makes me money to live.

  • One of pillars of success: manual (Score:5, Insightful)

    by Pecisk ( 688001 ) on Thursday June 09, 2005 @10:27AM (#12768602)
    Yes, that simple thing which is overused for learning and coding pratices. In the times when you are have to look for good perl manual, PHP manual from the very begining was perfect. That's it. And second best thing came when they added those comments for user experience.

    So, in any way, PHP is such thing which just works.

    Congrats! :)
    • I'm no programmer. I never have been.

      But I wanted to make a really cool web site for a game group I was in, and I dug into it. I found PHP, as it worked real easy with both apache and IIS.

      I ran through some tutorials (there's a ton of them out there, online, free) and I started to get into it.

      The PHP manual has a lot of information and detail about nearly everything the language can do. It's a reference but it's easy to read and you can sit down with it and learn a lot about PHP and programming in ge
    • Um, what are you talking about? 'perldoc' seems pretty good for me.

      As i recall, when i first started to get familiar with perl, i was using perl in 21 days, then switched to perldoc and cpan.org documentation.

      Also, please note the difference between a manual, a book and a guide. Manuals don't necessarily need to be easy to understandable, just coherent and clear. They are intended for those already familiar with the language, or at least some degree familiar with it. Given that php has so many functions
    • PHP manual from the very begining was perfect

      I think you got the causality backwards. If PHP's manual wasn't top-notch, then noone would ever be able to figure out the 15 variations on each function (each with arbitrarily different argument ordering). People didn't flock to the PHP manual because PHP is such a great language.

      In other words, PHP leans on a strong document set just to make it usable. That's quite different than most other languages commonly in use.

  • PHP/FI 1.0 wasn't really a scripting language, it was more like a big perl (or was it C?) script that would put some variables in a html page. Not really that useful but a nice idea.
    I discovered and started using PHP by the time the first beta of PHP 2.0 had been released. What a pleasure this was to convert my old clunky C CGI scripts to PHP. No more compiling, no more mallocs. Weee :)
    7 years (I think, maybe it's 6) later I'm still using PHP for everything at work, and I certainly don't plan to use anythin
  • Apparently, it was so slow to catch that it was posted a day late!

    Or is this a dupe from yesterday?

  • Success of PHP easy to understand (Score:5, Insightful)

    by iJed ( 594606 ) on Thursday June 09, 2005 @10:34AM (#12768694) Homepage
    I think it is obvious why PHP has become so popular:

    1. It is very easy to learn

    2. It is easy to use (unlike ASP.NET) and relatively simple

    3. The syntax is derived from C and perl

    4. It is free
    • 5. It features nice effects

      $test = null;
      if ($test==null) {
      echo "test is null";
      }
      $test = array("1","2");
      if ($test==null) {
      echo "test is null";
      }
      $test = array();
      if ($test==null) {
      echo "test is null";
      }

      reply with your suggested result ;-)
    • Two other big reasons are

      5. It's fast.

      6. It is easy for hosting providers to deploy. There are tons of hosting companies out there give customers PHP support because it is easier to support on a box running a bunch of vhosts. Other web scripting environmants either have security issues (mod_perl is really scary if you don't trust other people running on the same host), have limitations for what directories scripts are run from, or are just a PITA to deploy in a simple yet relatively secure way. (That's n

  • Looking forward (Score:4, Insightful)

    by joebp ( 528430 ) on Thursday June 09, 2005 @10:38AM (#12768740) Homepage
    Let's hope that in the future the PHP developers can come up with some ways to make the code produced by PHP developers more secure.

    One of the huge problems with PHP is the massive number of XSS and SQL injection vulns present in code. Partially because PHP is used by beginners, but mainly because PHP does not help the developer write secure code. It's fast and easy to write, but allows you to shoot yourself in the foot. Just like C. See this paper on precise tainting [virginia.edu] for an example solution to the problems. It would break compatibility with most software written in PHP, but that's not neccessarily a bad thing when most of it is insecure trash.
    • The real secret is PGP stands for Pretty Good Privacy, and PHP stands for Pretty Hopeless Privacy, hence the security holes!
  • Here's to you, PHP, five golden manbabies of the goldest sort.
  • I really think PHP's success is about one thing: cut and paste. When I didn't know squat about creating dynamic web sites, it was PHP that was the easiest to learn. All I had to do was cut and paste someone else's script into my HTML and voila! Also the installation, configuration, and documentation are excellent.

    But most PHP applications I've developed usually start simple but grow into a tangled mess of code. I've tried to seperate my programming logic using templating systems, but it's just so much e

  • I get it, but I don't want it (Score:3, Insightful)

    by Uzziel ( 148474 ) on Thursday June 09, 2005 @11:00AM (#12769021) Journal
    PHP is an abomination.
    It was very clever and very handy when it was first developed, but there are many much better systems for building web pages available today.

    Its object-oriented features are kludgy, its syntax is a throwback to C, and it in a realm where string handling is ubiquitous, it provides you with such great functions as strtok() and strncmp(). I mean come on, haven't we evolved just a bit past using the C standard library for string handling in our freaking web applications?

    Personal Home Pages is fine for whipping up a quick data-driven website, but if you want to build a large application it's crap.
  • I was born clairvoyant and was writing PHP code in womb. BTW, if anyone wants I can give you a heads up on Linux 6.6.6 and Windows WTF. Those come out AFTER the apocolypse.

  • Why I Like PHP (Score:3, Informative)

    by ajs318 ( 655362 ) <sd_resp2@@@earthshod...co...uk> on Thursday June 09, 2005 @12:02PM (#12769790)
    I like PHP because it's basically a bastardised dialect of Perl, and I like Perl.

    I like Perl because it uses different operators for string concatenation and addition. That doesn't sound like much of a reason, but a lot of the programming I'm doing seems to call for either adding numbers or concatenating strings.

    Now, in some languages, strings and numbers are completely different types. Then it's sort-of OK to recycle an operator to mean something completely different, because the computer knows what you mean. But there are several dynamically-typed languages which use + to concatenate strings. Then the magic guesser gets its knickers in a twist with not being able to work out whether something is really a number or just a string that looks like a number. This causes problems when you try to add numbers and find yourself concatenating strings. I wasted the best part of a day on a stupid bit of JavaScript for a DHTML application with increment/decrement buttons.

    In Perl {and in PHP}, 3 + 4 gives 7. "3" + 4 gives 7. 3 + "4" gives 7. And "3" + "4" gives 7. If you actually want to concatenate the 4 onto the end of the 3, you have to use the concatenation operator . instead of the addition operator +. 3 . 4 gives "34". "3" . 4 gives "34". 3 . "4" gives 34. And "3" . "4" gives "34". That is simple.

    Perl is a bit of a 'mare for n00bs because everything is a shorthand representation. There is the wonderful $_ which avoids cluttering up your script with temporary variables. You don't need brackets round function arguments {like the British BASIC dialects of the '80s}. Everything is optimised for the hardcore hacker, not the beginner. It only looks pretty when you realise that simplicity is beauty.

    PHP has a more consistent interface than Perl. So you can't just drop in a regular expression, you have to call a function with the regular expression inside a string. It also does more stuff automagically for you, like keeping hashes ordered {Perl doesn't bother, expecting you to keep a separate array if you really care} and dereferencing everything {Perl expects you to manually create and dereference references when you make multidimensional arrays}. So it's probably a bit slower running, but it's quicker to get an app up and running.

  • It's how you use it... (Score:5, Insightful)

    by sherriw ( 794536 ) on Thursday June 09, 2005 @12:30PM (#12770156)
    I've been developing website backends in PHP for 3 years, and large enterprise-scale apps for the past 1 year. It's a common misconception that PHP isn't appropriate for large applications.

    It's all in how you use it. Do you hack together a bunch of pages with isolated scripts talking to html forms and databases in an ad-hoc manner? Or did you start with a solid application design model from the start and follow through with time-tested methodologies?

    PHP gets a bad rep because of the large number of inexperienced developers using it with poor results. I've developed full CRM and ERP apps with it including invoicing and ticketing systems that scale beautifully and are a dream to maintain. PHP is fast, free, and easy to use.

    It's the responsibility of the developers to use more mature practices when developing large apps- and to recognize the fact that small site admin areas often evolve into larger apps. Plan and design!

  • We brought the cake (Score:4, Funny)

    by mgkimsal2 ( 200677 ) on Thursday June 09, 2005 @12:47PM (#12770366) Homepage
    http://phpweblogs.com/phpcake.jpg [phpweblogs.com]

    Yeah, we're a bit over the top for PHP. The whole company had cake and ice cream to celebrate. :)

  • Easy php installation (Score:3, Informative)

    by PsiPsiStar ( 95676 ) on Thursday June 09, 2005 @12:52PM (#12770432)
    If anyone needs an easy installation of PHP on a windows platform, try EasyPHP. The site is all in french, but it's free and good. It automatically installs and integrates PHP, MySQL and an Apache server.

    Personally, I've set up a lot of moodle sites (www.moodle.org) which is the best free LMS I've found.

    Check it out if anyone is into e-learning or web based training.

    (Make sure you have a fast server if you want to put a lot of students on it. The quiz modules are very useful, but they use an ungodly amout of resources if you're teaching a class of +30 students.)

  • Still broken. (Score:3, Interesting)

    by Pingster ( 14864 ) on Thursday June 09, 2005 @01:10PM (#12770749) Homepage

    Ten years and the == operator is still completely broken. Any hope of fixing it in the next ten?
    % cat test.php
    <?php if ("spam" == 0) print "I am insane."; ?>

    % php test.php
    I am insane.

    %

    Suppose A equals B, and also B equals C. Any reasonable person would expect that A equals C, right? Oh yeah?

    % cat equality.php
    <?php

    $a = 0;
    $b = "eggs";
    $c = "spam";

    print ($a == $b) ? "a == b\n" : "a != b\n";
    print ($b == $c) ? "b == c\n" : "b != c\n";
    print ($a == $c) ? "a == c\n" : "a != c\n";
    print ($a == $d) ? "a == d\n" : "a != d\n";
    print ($b == $d) ? "b == d\n" : "b != d\n";
    print ($c == $d) ? "c == d\n" : "c != d\n";

    ?>

    % php equality.php
    a == b
    b != c
    a == c
    a == d
    b != d
    c != d

    %
    Try explaining that to a first-time programmer.

Slashdot Top Deals

One man's constant is another man's variable. -- A.J. Perlis

Close