Slashdot Mirror


A Decade of PHP

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."

45 of 452 comments (clear)

  1. Congratulations are in order! by AKAImBatman · · Score: 3, Insightful

    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.

    1. Re:Congratulations are in order! by EraserMouseMan · · Score: 2, Insightful

      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. For my apps, all I have to do is change the connection string (currently supports, MySql, Sql Server, any Odbc and any OleDb). No query or code changes required necessary.

      But yea, it'd be nice if this functionality was native.

    2. Re:Congratulations are in order! by AKAImBatman · · Score: 4, Insightful

      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. :-)

    3. Re:Congratulations are in order! by mcrbids · · Score: 2, Insightful

      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 that sucker than with three others combined. Since I couldn't assume subselects, there was lots of parsed queries that resulted in additional bugs, etc.

      Pick a platform, then use it. If the platform is truly free, you aren't "locking" anybody at all, are you?

      --
      I have no problem with your religion until you decide it's reason to deprive others of the truth.
    4. Re:Congratulations are in order! by Just+Some+Guy · · Score: 3, Insightful
      If you think that "PHP" and "KISS" 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).

      --
      Dewey, what part of this looks like authorities should be involved?
    5. Re:Congratulations are in order! by rho · · Score: 2, Insightful

      Good points in your reply. Thanks for that.

      If I was interviewing someone and they presented me with sample code riddled with "pg_connect()" calls rather than abstracting that into its own library, my first question would be "tell me why it is bad to do this."

      Well, it all depends, doesn't it?

      First, there's a difference between coding an abstraction layer that facilitates interaction with your database, and coding an abstraction layer that handwaves away the peculiarities of any particular database. For example, if you have a function called "get_data_from_postgres_and_format_table()", that's an example of the first situation. Another way to do it that follows the second would be "format_table(get_data())", where the gathering of data from a database is generalized across databases, and the formatting of tables is done as a function of the application.

      In other words, putting all those "pg_connect()" calls behind something that helps you develop your application faster is a good thing. However, it does not neccessarily follow that then formalizing a set of database calls that dissolves the differences between PGSql and MySql and Interbase is also a good thing.

      I can use Drupal as an example, since I know it fairly well. The "Node" is the basic structure of the framework, and modules that extend the basic node must have the same ID as the node base. When presented, the node is a JOIN of the primary node and the extended node's tables. In Drupal, the work coordinating these is done by having, conceptually, a "get_me_the_next_node_id_number()" function and preventing future calls from grabbing that same number. This is all done in PHP, rather than simply saying, "Inser this and that in table 1 and table 2, and make table 2's ID equal table 1's ID."

      My arguments also do not apply to a good 75-80% of Web-based applications, most of which simply use the database as a less-dangerous way of accessing and storing data in the filesystem. They would be equally well-served by flatfiles, but don't because of the security issues inherent in allowing a Web server process to write to the filesystem. I'm not terribly familiar with PHPBB, but I imagine that there are multiple workarounds hand-hacked in PHP to accomodate those folks whose MySQL wouldn't know a foreign key from a stored procedure. All of these things introduce bugs, performance issues, and maintainability issues just as severe as any dependance on a single database vendor does--they're just different.

      I recognize that there are problems inherent in dealing with, say, PostgreSQL, but those do not go away with database abstraction. All database engines will have some level of maintenance issues--the benefit from depending on a single database is that you can codify the procedures in your documentation and maybe even your code--a cron-run script that automatically VACUUMs the database at 2:30AM--rather than weaseling out with a "The care and feeding of your database is beyond the scope of this document" disclaimer.

      Finally, this really only applies to larger PHP projects. I've found that when PHP is used to do something quick-and-dirty, it's almost always hard-coded to whatever database the programmer happens to have. It's only when that quick-and-dirty program starts to become popular does everybody clamor for "database independence", and then the author will comply. So, as an application grows in features and complexity, rather than leaning on the database to do it's job, the programmer doubles his work by re-inventing ideas, and re-learning mistakes, that database vendors dealt with 10 years ago, such as concurrency and performance issues. So, ironically, the best design decisions are made when it was just a little hack, and "creeping CS-isms" strike it as it gets more widely used, crippling the speed at which development can take place.

      --
      Potato chips are a by-yourself food.
    6. Re:Congratulations are in order! by cvd6262 · · Score: 2, Insightful

      Why climb to the top of a mountain when a helicopter is clearly the correct tool for that job?

      --

      I'd rather have someone respond than be modded up.

  2. What's not to get? by Enigma_Man · · Score: 2, Insightful

    Seriously, honest question. What's not to get about a language? It's just another language with different options, styles, formats, and uses...

    -Jesse

    --
    Nothing says "unprofessional job" like wrinkles in your duct tape.
  3. I don't really like PHP that much... by Anonymous Coward · · Score: 3, Insightful

    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?

    1. Re:I don't really like PHP that much... by sffubs · · Score: 2, Insightful

      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.

      --
      ݼ)s$æúßðíÊ'öX'îò5^àûßQç£
    2. Re:I don't really like PHP that much... by Anonymous Coward · · Score: 2, Insightful

      Amateur programmers, mostly.

      If you don't know a damn thing about web apps, PHP is easy to use and has a big community.

      *shrug* I think PHP is an awful awful language.

      The choices for function names, the global variables, the terrible value/reference confusion (still present in PHP5), the Java-like cruft, the lack of any decent metaprogramming facilities, the php.ini which means every installation is potentially different...ug. What a headache.

  4. Thanks for the career, PHP!! by ylikone · · Score: 5, Insightful

    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.

    --
    Meh.
    1. Re:Thanks for the career, PHP!! by downward+dog · · Score: 4, Insightful

      The poster makes a valid point: PHP is a marketable language. Whether it is good or bad, perfect or not, it gets the job done for some people. Myself included. I'll give Ruby a chance someday, but for now, PHP keeps my clients happy.

  5. One of pillars of success: manual by Pecisk · · Score: 5, Insightful

    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! :)

    --
    user@ubuntubox:~$ stfu This server is going down for shutdown NOW!
    1. Re:One of pillars of success: manual by Just+Some+Guy · · Score: 2, Insightful
      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.

      --
      Dewey, what part of this looks like authorities should be involved?
  6. PHP 1.0 - 2.0 - 3.0 ... by J-F+Mammet · · Score: 2, Insightful

    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 anything else (not that I could if I wanted, rewriting everything would take a few years...).
    Congrats to the PHP Team, and thanks !

  7. Re:PHP vs JSP by Frymaster · · Score: 5, Insightful
    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!

  8. Re:PHP vs JSP by NardofDoom · · Score: 4, Insightful

    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.

    --
    You have two hands and one brain, so always code twice as much as you think!
  9. Success of PHP easy to understand by iJed · · Score: 5, Insightful

    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

    1. Re:Success of PHP easy to understand by moof1138 · · Score: 2, Insightful

      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 not to say that PHP apps themselves are secure, but that you can set things up so that when you 0wn the PHP app you don't get much else.)

      --

      Hyperbole is the worst thing ever.
    2. Re:Success of PHP easy to understand by jpkunst · · Score: 2, Insightful

      If you use either if (is_null($test)) or if ($test === null) instead of if ($test == null) you get the expected results.

      JP

    3. Re:Success of PHP easy to understand by H0p313ss · · Score: 2, Insightful

      #6 is a BIG one, it's the only reason I'm playing with PHP rather than JSP or servelets.

      --
      XML is a known as a key material required to create SMD: Software of Mass Destruction
  10. Looking forward by joebp · · Score: 3, Insightful

    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 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.

  11. I get it just fine by Anonymous Coward · · Score: 0, Insightful

    Much easier than the crusty old languages of the past like Perl or God forbid Python.

    It's really easy for anyone to get up and running with PHP.

    The only potential issue is that virtually zero hosts actually enable any of the safe mode stuff (Note I'm not bothered by register_globals; way overhyped problem).

  12. Re:PHP definitely does not follow the KISS princip by Peter+Cooper · · Score: 2, Insightful

    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.

  13. Database independence by 3770 · · Score: 2, Insightful

    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.

    --
    The Internet is full. Go Away!!!
    1. Re:Database independence by stephenbooth · · Score: 2, Insightful

      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 faster time to market (don't have to reinvent existing code).

      Stephen

      --
      "Don't write down to your readers, the only people less intelligent than you can't read" - Sign on Newspaper Office Wall
  14. Re:PHP definitely does not follow the KISS princip by fbjon · · Score: 1, Insightful

    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?

    --
    True confidence comes not from realising you are as good as your peers, but that your peers are as bad as you are.
  15. Re:PHP definitely does not follow the KISS princip by lawpoop · · Score: 2, Insightful

    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.

    --
    Computers are useless. They can only give you answers.
    -- Pablo Picasso
  16. Re:PHP vs JSP by Neil+Watson · · Score: 2, Insightful

    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.

  17. I get it, but I don't want it by Uzziel · · Score: 3, Insightful

    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.

    1. Re:I get it, but I don't want it by aweiland · · Score: 2, Insightful

      PHP 5 OO features are far from kludgy (it's modelled after Java). Perl's so called OO is 10x more a kludge.

      What's wrong with the C string functions? They're fast, useful, and a lot of programmers know them. You're not limited to them. You can use split() or explode() to do what strtok does but get an array. Plus they are a hell of a lot better for dealing with strings than all of Java.

      And last I checked PHP stands for: PHP Hypertext Preprocessor.

  18. Re:Congratulations PHP by Black+Perl · · Score: 4, Insightful

    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.

    --
    bp
  19. Re:PHP definitely does not follow the KISS princip by killjoe · · Score: 3, Insightful

    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.

    --
    evil is as evil does
  20. Re:PHP vs JSP by ajs · · Score: 4, Insightful

    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.

  21. Re:Enterprise level systems by Peter+Cooper · · Score: 2, Insightful

    The fact you are using a Computer Science degree to back up your argument is telling. A Software Engineering would be useful, maybe, but a CS degree does not demonstrate you learned to develop enterprise level applications as this is not a focus of CS, as has been discussed many times in the "Shall I get a CS degree?" Ask Slashdot threads.

    I'm sure you are developing fine enterprise level PHP apps, but I can also crack open a Mac Mini with a fish slice. It doesn't demonstrate it's one of the best tools for the job, even if it does work. (This is why most low-level systems software is written in C, despite there being plenty of arguments that there's "nothing wrong" in using others.)

    And, yes, you're right, it's elitism. I'm elitist to the point where I feel that using any sub-par tool that's not suited to the task is not a wise long-term strategy. But, well, thanks for expressing that in some situations it seems to work.

  22. Re:Congratulations PHP by Peter+Cooper · · Score: 2, Insightful

    I consider this a good thing. The RoR community is of a decent size where development is moving on at a steady pace and documentation is, mostly, plentiful.. but not big enough that you're flooded with thousands of third-world developers coding at 10 cents a line. Not that the third-world developers are a particular problem.. people who think they can code in the West are also a major problem as they tend to quote peanuts and end up costing their customers big time.

  23. Not so good an idea by soloport · · Score: 3, Insightful

    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.

  24. Career by daeg · · Score: 2, Insightful

    I, too, have PHP to thank for a wonderful career. While I know that PHP is not the best language for the massive applications I've done, PHP developers are relatively easy to find and train. That is a major marketing factor for companies. Rails is great but how many (available!) workers are there? Very few. Same with Python. PHP can be very powerful when done right. The last major system I wrote with it included a call center (using the wonderful company Voxeo for hosting) that dropped right into the CRM and loan processing software. The current system includes a self-running tiered hosting system (Bind 9, Apache 2, PHP 5.1-dev, PGSQL 8); the daemons (written in PHP) detect server load and move sites accordingly to other slaves.

  25. Re:Congratulations PHP by Anonymous Coward · · Score: 1, Insightful

    umm. no-one said RoR is the first MVC framework. Its just the first one that's made for humans.

  26. It's how you use it... by sherriw · · Score: 5, Insightful

    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!

  27. Re:Congratulations PHP by rho · · Score: 3, Insightful
    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.

    --
    Potato chips are a by-yourself food.
  28. Re:Could someone compare and contrast it to perl by Anonymous Coward · · Score: 1, Insightful
    PHP is a domain specific language for developing dynamic websites.

    Perl is a language optimized for scanning arbitrary text files, extracting information from those text files, and printing reports based on that information. It's also a good language for many system management tasks.

    Hope that helps.

  29. Re:PHP definitely does not follow the KISS princip by julesh · · Score: 3, Insightful

    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.

  30. Wrong, wrong, wrong by weston · · Score: 2, Insightful

    "you can use Perl's regular expressions in PHP."

    Nope. You can't. Well, you can. Well, sortof. Sometimes. With some syntactical exceptions, and lots of thinking about escape sequences, and passing parameters a different way. And that's the gotcha. You start thinking it's going to be the same -- and it's not.