Forgot your password?
typodupeerror
PHP Programming

PHP 5.5.0 Released 219

Posted by Soulskill
from the onward-and-upward dept.
New submitter irventu writes "The long-awaited PHP 5.5.0 has finally been released, bringing many new features and integrating Zend's recently open-sourced OPcache. With the new Laravel PHP framework winning RoRs and CodeIgnitor converts by the thousands, Google recently announcing support for PHP in its App Engine and the current PHP renaissance is well underway. This is great news for the web's most popular scripting language." The full list of new features is available at the Change Log, and the source code is at the download page.
This discussion has been archived. No new comments can be posted.

PHP 5.5.0 Released

Comments Filter:
  • by Anonymous Coward on Friday June 21, 2013 @09:19AM (#44069969)

    I'm still waiting for a PHP 6.0 that's an actual rewrite without all the stupid. With every new version, I just see more features get tacked on ("Objects").

    It's wonderfully backward compatible because nothing really gets removed in newer versoins, but it would be nice if the language could be made more pleasant to use.

    • by Anonymous Coward on Friday June 21, 2013 @09:29AM (#44070041)

      The thing that bothers me most is the inconsistency in function names or argument order. When I'm using PHP, I have to constantly keep looking the functions up to make sure its doing what I expect.

      • Re: (Score:2, Redundant)

        by Krojack (575051)

        Oh hellz yeah. Glad I'm not the only one this annoys.

      • by gbjbaanb (229885) on Friday June 21, 2013 @10:01AM (#44070315)

        so do I.. but then, I'm old and I have to do that for everything. Maybe its not the language after all.. just saying :-)

      • by thetoadwarrior (1268702) on Friday June 21, 2013 @10:41AM (#44070671) Homepage
        This is one of the biggest problems. It's a horrible language to look at. The carelessness carries through the community too. You simply can't trust third party to be anything but amateur. But who can blame PHP devs when the core language is cack and the documentation is laughable.
        • by gorzek (647352)

          What I've found to be truly bizarre is that a lot of the official documentation makes no sense, in and of itself. It's vague and difficult to interpret. You normally have to scroll down to the comments to see how people actually use it, and it's only at that point that the function in question begins to make any sense. The documentation itself is just too barebones to be adequate.

          Python's practice of including simple examples with the documentation of virtually every command and function and feature is incr

        • by Bert64 (520050) <(bert) (at) (slashdot.firenzee.com)> on Friday June 21, 2013 @11:01AM (#44070837) Homepage

          Part of the problem with PHP is that it's designed to be simple to pick up... Many people start by just adding one or two simple PHP tags to an existing HTML file and go from there.

          No need to learn a development environment, no need to create archives or packages, quite literally anyone can create their first "dynamic" webpage by adding one line of php to an existing html file, many people do something really simple like just show the current time etc.

          This accessibility has a price, because php is accessible to people with little or no experience of writing code, then lots of such people use it and this often results in very poor code. It's perfectly possible to write very clean code with PHP, you just have to look for it amongst all the thousands of novice programmers turning out junk.

          • Indeed it is extremely simple to pick up and therefor fills a person with joy at the power they have acquired. The joy quickly fades when you realize what you have to go through to build a real application. I'm interested in Laravel.

        • Re: (Score:3, Insightful)

          by Dracos (107777)

          Hey, don't blame all of us for Wordpress.

        • by garyebickford (222422) <(moc.liamg) (ta) (cib73rag)> on Friday June 21, 2013 @12:09PM (#44071517)

          Ha. As a programmer in at least two handfuls of languages over 40 years from IBM 1130 ASM, FORTRAN, ALGOL 68, Pascal, Basic (ick), APL, etc., and long time programmer in PHP, I am presently in the process of hacking up someone else's Perl.

          Nobody who writes in Perl can have anything to say about the structure, style or consistency of PHP. PHP may have grown like topsy and it could certainly use some revision of function argument order, but it at least uses a syntax that is remotely similar to other common imperative languages - java, c, etc. From my first look at Perl in 1995 I always thought Perl looked like sneezing, and now I'm working with it, my first impression was correct. (Although in fairness I use PCRE in PHP quite a lot!)

          This is my most recent 'fave' quote from perlsyn - on 'when', which is part of Perl's attempt to rethink (or something) the switch/case pattern [perl.org]:

          Exactly what the EXPR argument to when does is hard to describe precisely, but in general, it tries to guess what you want done. Sometimes it is interpreted as $_ ~~ EXPR, and sometimes it does not. It also behaves differently when lexically enclosed by a given block than it does when dynamically enclosed by a foreach loop. The rules are far too difficult to understand to be described here. See Experimental Details on given and when later on.

          Pathologically Eclectic Rubbish Lister [perl.org] indeed!

          Since I'm on a role here, I will complain about one thing in Python, though I've only programmed a bit in Python. Python's much vaunted 'indent' based nesting is a mistake, because it only uses one invisible marker (which may be instantiated by several symbols - spaces and tabs, at least) to do this. All other common languages I can think of use different markers for begin and end, which acts as a kind of 'double entry bookkeeping' for the parser. Without a closing marker, Python's parser has no way to catch errors in leading spaces.

          A similar type of error results from C's syntax, which was unfortunately adopted in PHP - in allowing action inside a conditional "if ($foo = 1 + $bar)", the poor parser has no way to know if one really means 'compare' or 'assign'. This is the cause of innumerable bugs in both languages. This could be fixed by requiring assignments inside a conditional to be surrounded by block markers: "if ({$foo = 1 + $bar})".

          But I like all 'scripted' languages better for my purposes (entirely applications, no device drivers or kernel work) than C and other 2nd generation languages. I've had exactly one segfault working with PHP, in nearly 20 years.

          • by PCM2 (4486)

            A similar type of error results from C's syntax, which was unfortunately adopted in PHP - in allowing action inside a conditional "if ($foo = 1 + $bar)", the poor parser has no way to know if one really means 'compare' or 'assign'.

            I don't understand. I'm not a parser, but to my eye that means "assign." If you wanted to compare, you would do "if ($foo == 1 + $bar)", no?

            • A similar type of error results from C's syntax, which was unfortunately adopted in PHP - in allowing action inside a conditional "if ($foo = 1 + $bar)", the poor parser has no way to know if one really means 'compare' or 'assign'.

              I don't understand. I'm not a parser, but to my eye that means "assign." If you wanted to compare, you would do "if ($foo == 1 + $bar)", no?

              Ah, but in C, and thereby in several other languages that have adopted C syntax, the result of the assignment becomes the value of the conditional, so "if ($foo=1+$bar)" means, 'add one to $bar, assign it to $foo, then evaluate the conditional based on the value of $foo'. Maybe that's what I meant to write, but maybe I just mistyped. So thus arises an ambiguity - did we mean assign and then evaluate, or just compare? And thus bugs are born. It is quite easy to accidentally put '=' when we mean '=='. Bu

          • Yeah, Python. I got excited about it becasue the web was a-buzz with Python love. Installed it, started playing, about puked, uninstalled it. Fuck the white-space shit. Are brackets really annoying that many people? Is there a reason to break away from C-block formatting?

      • Yeah no kidding. Another big gripe of mine is how most of the things that you'd like to try/catch doesn't throw an exception, but some sort of "notice" or "warning", which you cannot respond to. I've managed to work around this by implementing custom error handlers, but that brings its own problems when other peoples' code expects the default behavior. What's worse is the stuff that throws warnings/notices are things that are very basic: accessing an array element that doesn't exist, opening a file without

      • is_null and isset for example. I hate these functions. From what I understand someone thought it was a good idea to copy some C function names, which I think just makes the inconsistency worse.

      • by jsdcnet (724314)
        You need a better IDE. I use Netbeans and Sublime Text (mostly ST these days) and as soon as I start typing the function name, both editors give me a completion popup with placeholders for the parameters.
    • by squiggleslash (241428) on Friday June 21, 2013 @09:46AM (#44070199) Homepage Journal

      what_have youGot AGAINST $_THEWAY PHP works($dummy, WORKS_TODAY)? I think it's==great, wait, sorry I mean "I think it's===great." - I accidentally passed in null and that last condition gave me a bunch of false positives.

      I'm hoping PHP6 will finally give programmers the ==== and ===== operators we've been waiting for.

      • by i_ate_god (899684) on Friday June 21, 2013 @10:01AM (#44070319) Homepage

        == and === are common in dynamically typed languages

        assert 1 == true //works
        assert 0 == false //works
        assert 1 === true // fails
        assert 0 === false // fails

        • by kbolino (920292) on Friday June 21, 2013 @10:15AM (#44070453)

          Indeed, but the problem is type coercion and not dynamic typing. You can have a dynamically typed language that does not coerce unlike types to make life "easier".

        • by squiggleslash (241428) on Friday June 21, 2013 @11:28AM (#44071059) Homepage Journal

          While that's true, the complaint isn't that PHP has a dynamic typing system and has some operators that reflect that, it's that the coercion and comparison rules are... not exactly easy to predict. Not to mention the fact === works the way you'd expect == to work, with == performing non-intuitive coercion to try to find a way to make different things the same.

          assert(""==false);
          assert(0==false);
          assert("0"==false);
          assert(null==false);

          All of these will succeed.

          * Intuitively to a non-PHP programmer, only the second one should.
          * A PHP programmer with experience will, on the other hand, note that given "echo 1==2" products no output, only the first should be guaranteed to succeed with the second one maybe kinda succeeding.

          The others? Dubious at best. The third should always fail, because "0" != "false" and "0" != "" (but PHP is doing the wrong coercion so it instead converts the string to a boolean rather than vice-versa), the fourth treats null in a way that almost makes SQL look logical.

          Ironically, your observation makes my joke more accurate than originally intended. Given the behavior of == is not what's needed in a dynamically typed, softly typed, language, and === provides only one of the legitimate comparison operators necessary for such a language, we do, actually, need an ==== operator in PHP. Scary, huh?

          • by pinkeen (1804300)
            You forgot about this:
            assert("hello" == 0); will succeed, but
            assert("1" == 0); and assert("1hello" == 0); will fail.

            Starting to see a pattern here?
          • It's a language designed for the web. When you submit a form, everything is a string (or a file), there are no ints or floats. So, the language has to work around this issue, and being loose-typed, and having two comparison operators that work they way they do, is part of what makes PHP easy to use for the web.

            Cheers.

            • You're missing the point I was making. I wasn't criticizing it for doing coercion, I was criticizing it for doing the wrong coercion, with the result that the "==" operator's behavior is difficult to predict.

              If you read the GP, you'll see I was responding to that point.

              • assert(""==false);
                assert(0==false);
                assert("0"==false);
                assert(null==false);

                When a form is submitted, there is no bare 0, there is only "0", so PHP treating "0" as if it where 0 in certain cases is certainly understandable. It may not be obvious or intuitive to you, but there is certainly a good reason for it.

                See also: PHP type comparison tables [php.net]

                A comment on that page says:

                just remember the following are always FALSE:
                null, false, "", 0, "0", array()

                Hardly complicated.

                • but there is certainly a good reason for it.

                  No, there isn't. There's a bad reason for it. It would be a good reason only if you would expect all data comparisons to be with form elements, and for those form elements to be that limited range of textual responses. Notably "false" and "off" are not false, according to ==. Remember that == is not a "Use this for some form fields when you're doing comparisons" operator, it's the one people are expected to use by default, with "===" being added to the language

                • by mypalmike (454265)

                  "Hardly complicated."

                  s/Hardly/It's/

      • by TheSpoom (715771)

        Honestly I find == good enough for normal usage in PHP. Javascript is another matter.

        • So you've never searched a string for a token?
          • by TheSpoom (715771)

            strpos and friends are one of a few exceptions, to which developers are prominently alerted in the documentation.

            • They could've just gone with -1 as a return value and had no problems; it's not like PHP stops you from doing substr($foo, false)—in fact, it casts false to 0 and returns the whole string.

              But that's just the thing: there are so many documentation-requiring exceptions of various kinds that you can't program without keeping the documentation open. I've written pretty large applications in PHP (including a full interpreter for a scripting language) and there's a true paucity of consistency. No other lang

    • by Megane (129182)
      A PHP that isn't a fractal of bad design? [veekun.com] Unpossible.

      I can’t even say what’s wrong with PHP, because— okay. Imagine you have uh, a toolbox. A set of tools. Looks okay, standard stuff in there. You pull out a screwdriver, and you see it’s one of those weird tri-headed things. Okay, well, that’s not very useful to you, but you guess it comes in handy sometimes. You pull out the hammer, but to your dismay, it has the claw part on both sides. Still serviceable though, I mean, you can hit nails with the middle of the head holding it sideways.

    • by gmack (197796) <gmackNO@SPAMinnerfire.net> on Friday June 21, 2013 @09:59AM (#44070301) Homepage Journal

      Because then some people would have to stop updating? The place I work has code dating back 10 or 11 years and the programmers already have to go through the code each update to see what got dropped and even then there will be demands for the upgrade to be rolled back or "delayed" (moved to a point in the future that never happens because they never have time for it).

      It's not just in house stuff that doesn't update either, Check out large Open source projects and see how many of them generate warnings related to deprecated functions.

      If you want a language that has no cruft there are languages you can switch to but not many people use them for the reasons stated a above.

      • If you want a language that has no cruft there are languages you can switch to but not many people use them for the reasons stated a above.

        Cruft is there for a reason. [joelonsoftware.com]

        What the computer does is complicated. We use the written high level language to generate the instructions that the computer actually executes to "do something." The instructions are what "do something." Someone might stare in puzzlement at why some seemingly irrelevant value is bit-shifted right 8 bits. No reference in the code to it. BUT

    • by ccguy (1116865)

      I'm still waiting for a PHP 6.0 that's an actual rewrite without all the stupid.

      Here you are (just run on shell):

      tar cvfz php-6.0.0-stupidless.tar --files-from /dev/null

      You're welcome.

    • by greg1104 (461138)

      Perl had a good sized install base and a healthy community, and then they tried this with Perl 6.0. Can't imagine it would go any better for PHP.

    • Re: (Score:2, Interesting)

      by Anonymous Coward

      I'm still waiting for a PHP 6.0 that's an actual rewrite without all the stupid.

      And I'm still waiting for all the PHP haters to fork it and create a new version and "do it right." The language is open source, you know.

      Evidently none of the self-proclaimed "experts" in programming language design is willing to fix PHP.

    • by gmuslera (3436)
      The problem is the "small" amount of legacy code. Even with the big amount of deprecated features, a lot of unconsistent (to be generous) things is still there. And if there is not a smooth transition, will be hard that a mass migration happens. Even if the goal is to get a good, consistent language, with good object orientation for version 6, think how much time is taking for Perl 6.
    • by pmontra (738736)

      I read the Laravel page and it's great to see how closely they managed to mimic Ruby and Rails (I used "and" on purpose). However it also exposes the limits of the language.

      This PHP

      $tasks = User::find(1)->tasks;
      $author = Task::find(5)->user()->username;
      $task = new Task([ title: 'Go to store.' ]);
      User::find(1)->tasks()->insert($task);

      would be this Ruby

      tasks = User.find(1).tasks
      author = Task.find(5).user.username
      task = new Task({title: 'Go to store.'}) # but the {} are idiomatically remove

  • Bugs & Maintainers (Score:5, Informative)

    by TheNinjaroach (878876) on Friday June 21, 2013 @09:24AM (#44069995)
    I participated in beta release testing for 5.5 and I'm frustrated that it still has old bugs [php.net] that cause segfaults that continue to go ignored by the maintainers. I even supplied the patch and submitted a Github pull request, but the maintainers continue to ignore it.

    It's no fun having to keep our own custom patchsets for PHP just to keep it running properly.
  • Citation needed (Score:5, Insightful)

    by benjymouse (756774) on Friday June 21, 2013 @09:37AM (#44070109)

    With the new Laravel PHP framework winning RoRs and CodeIgnitor converts by the thousands

    Citation needed. Why does the summary contain this blurb which is not even relevant to the story. Me suspects that the submitter could be an advocate who just ceased on an opportunity to tell slashdot about his favorite PHP framework.

    • by dkleinsc (563838)

      just ceased on an opportunity

      I don't think that means what you think it means.

  • by Anonymous Coward on Friday June 21, 2013 @09:39AM (#44070135)

    You only need a peek to see this Laravel dubbed "PHP renaissance" does not even try to be statically safe. It's littered with pitfalls like writing your validators with strings, such as: "array('name' => array('required', 'min:5')), ...".

    (It is possible to write statically typed validators, with clean syntax (depending on language) and you end up not loosing stuff like auto-completion, semantic checking by IDE etc. See for instance latest Scala PlayFramework and it's JSON validation, it is relatively easy to use, and syntax is surprisingly succinct taken the fact it's extremely type-safe.)

  • PHP renaisaunce (Score:2, Offtopic)

    by Chrisq (894406)
    I guess that's when everyone gathers around dressed in renaissance costumes, drink warm beer, speak in mock-British accents, and reminisce on the times when knights were bold and PHP was cool
  • Really? (Score:5, Insightful)

    by LizardKing (5245) on Friday June 21, 2013 @09:41AM (#44070153)

    With the new Laravel PHP framework winning RoRs and CodeIgnitor converts by the thousands

    Citation please.

    • Re: (Score:2, Interesting)

      by Anonymous Coward

      Yeah, I'd like a citation, too. I'm a RoR developer and had never heard of Laravel. Looking at the syntax in the Laravel quick-start brings back bad memories, though. PHP just isn't very good at DSLs.

      • Re: (Score:2, Funny)

        by Anonymous Coward

        I'm a RoR developer

        And you admit this publicly?

    • Citation please.

      "With self-discipline most anything is possible." ~ Theodore Roosevelt

      *ducks*

    • Re:Really? (Score:5, Funny)

      by Chris Mattern (191822) on Friday June 21, 2013 @10:06AM (#44070375)

      Citation please.

      Okay. How's this? [wikimedia.org]

      • by columbus (444812)

        Damn, I wish I had mod points. That was good for a chuckle. Thanks.

  • by MikeRT (947531) on Friday June 21, 2013 @10:09AM (#44070393) Homepage

    Is for someone to write a new standard API that can sit in parallel to their old one that gives us sanity like string manipulation functions with real names and consistent parameters. You know stuff like:

    $x = string::indexOf($source, $needle);

    and

    $x = string::replaceAll($source, $needle, $regularExpression);

    • How about the obvious on OO?

      $x = $source->indexOf($needle);

      and

      $x = $source->replaceAll($needle, $regularExpression);

      ?
  • Yeah, I'm sure (Score:5, Insightful)

    by Trailer Trash (60756) on Friday June 21, 2013 @10:11AM (#44070421) Homepage

    With the new Laravel PHP framework winning RoRs and CodeIgnitor converts by the thousands...

    CodeIgnitor? Maybe. RoR? Um, no. Or, perhaps, in your dreams.

    As an RoR developer who left PHP years ago I assure you - we aren't just waiting for a really good PHP framework that's an RoR knockoff. Part of the greatness of Rails is Ruby, and looking through the Laravel docs just confirms that. It looks like Laravel is about as nice as you can get on PHP, but ultimately it's still PHP underneath (and on top).

    Rails is a meta-language built on top of Ruby. Just can't do that in PHP.

    And that's not even getting into the ugliness of PHP's cruft that's been built up over the years.

    • There are RoR developers left? Seriously? I've not heard much about RoR after the $500k I made circa 2009/2010 coming in and cleaning up the mess on a few projects. Ironically enough it often involved rewriting projects mostly in PHP, but others in C# or Java, and even sometimes even with Perl. Granted most of the problem was non-developers reading how RoR does all this stuff automagically for them, they don't have to think or know, and turning out a blog in 15 minutes some how makes them a "developer"

  • by Boss, Pointy Haired (537010) on Friday June 21, 2013 @10:11AM (#44070423)

    Yes it has its flaws, yes you sometimes don't know whether you're looking for needles in haystacks or haystacks in needles, but it's not like they're not aware of that, and it's not really a big deal either in these days of syntax and function aware editors and instant online reference, and it has provided me and i'm sure many thousands of other people with a career not just in contract coding but also in being used almost exclusively on our own websites.

    Thanks guys!

  • Guilty pleasures (Score:5, Interesting)

    by EmperorOfCanada (1332175) on Friday June 21, 2013 @10:38AM (#44070645)
    I have two guilty pleasures: Watching the show COPS, and programming in PHP.

    I dream about getting away from PHP and occasionally dip my toes in other waters (Python, Java, and even C++) but always come back to PHP. I won't go to Ruby for as many websites start with Ruby and then abandon it for many other languages. People blah blah about MVC but often what I am doing is just too damn simple to need such added complexity. I might need a program that I occasionally run to view a list of spam flagged submissions; it is done in 10 minutes in PHP. I don't use any frameworks and am diligent enough to keep things running through prepared statements and whatnot. With opcode caching and memory caching of data PHP is very very fast.

    It is not so much that PHP is the best at anything it is that it isn't really terrible at anything I care about. Almost every other language is terrible at at least one thing that I do care about.

    Personally I think that PHP gets its bad rap because it is a very easy transition from HTML. So you have basically non programmers starting to sprinkle PHP into their HTML and oddly enough an untrained programmer's first efforts end up being crap. Then because PHP covers all the web server basics these programmers potentially never venture beyond PHP and there is nothing better for making a bad programmer than a one language programmer. (Not someone who primarily programs in one language but one who only ever learned the one language) So these same programmers keep expanding the scope of their terrible code.

    So if anyone can suggest a programming language to replace PHP I would love to know (and all JVM languages are off my list).
    • Re:Guilty pleasures (Score:5, Informative)

      by Samantha Wright (1324923) on Friday June 21, 2013 @11:07AM (#44070865) Homepage Journal

      There are a lot of very real technical reasons why people don't like PHP. The syntax and naming of its function library is inconsistent, the type coercion is irregular, and it's inconsistent about warnings vs. errors—it tends to keep executing code even when it shouldn't, potentially leading to unwanted behaviour during development if a variable isn't set or something. Reddit has a fairly active board devoted to the various problems [reddit.com] that can occur, not all of them avoidable.

      One of the most peculiar details in all of this is that PHP's original author (and, I think, but don't quote me on this, a portion of the development staff) considers himself a non-programmer; that PHP was just thrown together to simplify work. That would be okay, but it's led to a lot of security holes, bugs, and irreversible bad choices over the years, like having to use === in string parsing because false is returned by strpos() if it doesn't find anything (and false == 0). No other language requires this particular quirk.

      I don't blame you for not liking Ruby. While it's a much cleaner language, it's got some very peculiar syntactical features that make a lot of people scratch their heads—most notably, there are circumstances under which return doesn't work normally [stackoverflow.com], which can be very frustrating. However, there are some very creative uses of familiar syntax that, for example, make strings really easy to work with; haystack['needle'] = 'thread' is the same as $haystack = str_replace('needle', 'thread', $haystack) in PHP. I haven't used it personally, but I think the major reason Ruby projects get abandoned so much is because the people writing code in it are not experienced programmers.

      Running down the list a little and hopping over JVM stuff, the other decent web languages you may want to consider are Perl and Python. Both have extremely well-developed libraries and are good with strings, so it's mostly just a question of picking "esoteric and terse" vs. "newbie-friendly and easily maintained." Decent JVM languages include JWT, Scala, and Clojure (with noir [chris-granger.com]; check out that sexy beast), although JWT is probably overkill for anything smaller than Gmail.

      • I just replied elsewhere about my recent experience with Perl - Perl makes PHP look like a paragon of consistency and well-designed code. But I do like Perl regular expressions - as implemented in PHP! :D

        Python's use of a single, invisible marker for blocks - the indent - is a mistake that causes a lot of bugs. Blocks need different begin and end markers to allow the parser to know what goes where.

      • by Wdomburg (141264)

        Return works fine; trying to return from something that isn't a method doesn't. The most striking thing about this question is that the submitter never explains what they are doing or why they insist on doing it in a non-idiomatic way. "I'd really prefer to be able to use 'return' in this scenario" is not a compelling argument. What reason did he have for trying to work around a reasonable, well established language paradigm?

        As far as people abandoning Ruby, I'm not sure it is more or less common than ot

      • Yes I did perl from around 1996 to 2000, then Java around 2000 (It really wasn't meant for web at the time), then .net around 2002 (It wasn't meant for the web at the time either), then PHP around 2004. Since then I have taken cracks at just about everything but lisp and Scala. Still keep going back to PHP.
        Oh and str_replace has fooled me many times so I now use preg_replace. Little harder but much cooler.
      • by columbus (444812)

        I like your link to a page containig a picture of a hammer with a claw on both ends.

        I raise you a link to a page describing a pentagonal room. PHP: a fractal of bad design.
        http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/ [veekun.com]

        I cant believe nobody has linked to that blog posting yet. It's a classic.

      • "it tends to keep executing code even when it shouldn't" and exit unexpectedly when you do not want it to.
        You could not make a language handle exceptions any worse than PHP.

    • by Bigbutt (65939)

      Actually I'm in the same boat. PHP works fine for all the little things I do and even a few big things. I've tried poking at Ruby a little and wasn't interested enough to pursue it. While I've done C programming in the past (80's and 90's), and perl (90's and 00's), most of my more recent work is scripting in general; shell scripting, some perl stuff, and loads of PHP+MySQL+JavaScript.

      I have asked the same question in past PHP rant threads but with no response.

      [John]

    • People blah blah about MVC

      My company has been using the MVC framework CakePHP for quite a few projects over the last few years. It never seems to get any public attention, but it works really well for us and has a lot of nice features.

      • by pmontra (738736)
        CakePHP 1 was really difficult to read. I had to work with it and all I remember is that the signal was so obscured by tons of array() and strings with the names of models that the meaning of the code was difficult to understand (I was used to Rails). I remember that Symfony was cleaner, but still not so good. Hopefully CakePHP 2 got better but I never had to work with it so I can't compare it with Rails. Laravel looks like something that can be used, notwistanding the limits of PHP.
      • Can't do Cake as it is too slow. Google beats your search results if your site isn't uber fast. Thus a site using raw PHP will be on page one while an identical site with Cake will be on page 8. This is one of the reasons I am tempted to make the mega leap to C++ for web apps.
    • I love Perl for its regular expression use. It is so incredibly easy to do so many things after you realise how easy Perl makes RE use. I also think how it handles classes is cute, if not all that usable. But the rest of the language is pretty much crap.

      PHP is quite nice, but does a bunch of stuff a little off and is quite general at everything,

  • Given that I've seen exactly zero PHP programs running as scripts outside of a webserver environment, I'm calling bullshit on the idea of PHP being a scripting language, let alone "the web's most popular" one.

    • by pmontra (738736)

      Actually phpunit runs scripts from the command line but yes, usually they are tests for code that eventually runs in a webserver. Anyway a large and well done PHP project has much more code in models, controllers and libraries that in HTML views so it's not easy to say that it's just a templating language.

      About being the most popular, it probably is. It's either it or Java or some .NET language. Python and Ruby are following at a distance. Given all the free or cheap PHP hosting servers my bet are on PHP. B

  • Being stuck developing on other peoples servers.

    One thing I found very strange was how much it matters. It is surprising how many necessary, basic features have just been added.

Nothing will dispel enthusiasm like a small admission fee. -- Kim Hubbard

Working...