Forgot your password?
typodupeerror
This discussion has been archived. No new comments can be posted.

PHP Finally Getting a Formal Specification

Comments Filter:
  • by nimbius (983462) on Thursday July 31, 2014 @02:29PM (#47575953) Homepage
    As a devops (christ i hate that word.) engineer, the fact that the lack of a formal specification was overlooked for 20 years has been and is currently a big red flag for any legitimate software project. It was the knee-jerk reaction to Jakarta/Tomcat/Struts and ultimately java based, head first strict-type coding that turned programming projects into concentration camps. It emerged during a period when programmers were still struggling to determine how to present content to users sustainably, instead of having to write the entire page in perl. IMHO this is too little too late.

    This is entirely opinion, but having lived with web n.x for 15 years, Python has emerged a juggernaut to contend with in RESTful coding environments. it learned from PHP's mistakes and walked away from perl with a firm understanding of what made it uncomfortable from the debug standpoint. things like CherryPy, TurboGears, pylons and even pecan can turn a proof of concept in a day, and can easily and quickly be scaled across the infrastructure.
    • by OzPeter (195038) on Thursday July 31, 2014 @02:57PM (#47576189)

      Python has emerged a juggernaut to contend with in RESTful coding environments.

      Putting aside the whole whitespace debate(*), I'm pretty sure that python has its own list of issues. Maybe not to the same extent as PHP, but they exist.

      * For which I personally do have trouble with python - I want the computer to bend to my will, not the other way around.

      • Putting aside the whole whitespace debate(*), I'm pretty sure that python has its own list of issues. Maybe not to the same extent as PHP, but they exist.

        Picking a programming language is like picking an application, though. It's not about picking the syntax. That's not particularly relevant unless you're looking at Brainfuck or INTERCAL or GW-BASIC. You start by deciding what capabilities you need. There are inevitably several choices that meet your technical requirements, so in the end you're picking a language based on whatever set of limitations and issues you're willing to work with.

        • Then I did it 30 years wrong.
          Picking languages by syntax, shame on me.
          Perhaps I should now try a Lisp like language finally?

          Wtf, what nonsense ... what language has a capability another language has not? Wow, now we are at language paradigms, functional, oo etc.

          A language should either be a DSL or oo or at least functional, if it is neither, it is close to useless (yes, that includes C) and I certainly won't use a language that hurt my eyes and where I have in simple situations to think about 'syntax'.

      • by rdnetto (955205)

        Putting aside the whole whitespace debate(*), I'm pretty sure that python has its own list of issues.

        My understanding is that Python's two biggest issues are a lack of static typing (justifiable, but annoying) and the ability to use arbitrary objects as dictionaries. The latter causes significant issues when trying to optimize code, because something as simple as reading a value from a property becomes a hashtable lookup.

        • Most high level scripting languages (can't speak for PHP, but it's true for Perl, Ruby and Python) implement simple user defined objects as dictionaries. That said, the lookup cost, while obviously much higher than pre-compiled v-tables, are not as expensive as you might imagine; attribute access uses interned strings, and strings cache their hash code on first hash. If you don't actually have to recompute the hash, and equality checks are (for attribute lookup) a simple reference identity test, the CPU cos

          • Nice to know how that works, but ordinary languages like C++ and Java etc. don't need a v-table to access attributes.
            The offset into the 'record' is calculated by the compiler, so accessing it is just 'base pointer' + 'offset'. Like in Pascal and any other language supporting something like a 'record'.

          • FWIW, in answer to your "Can't speak for PHP" thing, PHP has, for reasons known only to the person that implemented, two incompatible dictionary type structures, objects and arrays. They're both equivalent, and because they're not compatible an enormous number of developers of third party libraries and frameworks feel the need to implement a "Give me it as an object"/"Give me it as an associative array" parameter onto any function that returns one or the other.

            And lest you think "Wait! It's obvious squig

        • by macson_g (1551397)
          Want static typing? Use Cython.
        • by jambox (1015589)
          Those aren't issues, they're features. Lack of static typing (odd choice of words - you could say Java lacks dynamic typing) allows much sparser code and you don't have to waste time compiling. The downside is there's more chance of runtime errors, but the time you've saved probably makes up for it and hell, you've got time now to write those unit tests. Performance isn't Python's strong point, but there are lots of options. For example, if you want to parse XML, ElementTree has a fantastic API and is writ
      • I'm pretty sure that python has its own list of issues. Maybe not to the same extent as PHP

        Understatement of the century. Elliot Rodger didn't have issues to the same extent as PHP...

      • by narcc (412956)

        I'm pretty sure that python has its own list of issues. Maybe not to the same extent as PHP, but they exist.

        Python's problems are far broader and deeper than PHP's. At least with PHP, there isn't anything fundamentally wrong with the language. Python, on the other hand, is beyond salvation.

        Just one example: The whitespace issue isn't simply a matter of personal preference. It's why Python will NEVER have anonymous functions without laughably absurd limitations.

      • by tlhIngan (30335)

        * For which I personally do have trouble with python - I want the computer to bend to my will, not the other way around.

        A good syntax highlighter would easily point out where you mixed tabs and spaces together by highlighting the offending error in red.

        And Python's pretty flexible, actually - if you use a tab to indent, then use spaces, that's allowable, as long as you always use tab then spaces on that block. Tab-tab is an error, as is spaces-tab.

        The other advantage is it kills of the debate of where the b

      • Putting aside the whole whitespace debate(*)...

        * For which I personally do have trouble with python - I want the computer to bend to my will, not the other way around.

        Do you only use languages that let you choose the language keywords? Surely there is leeway in how much bending to your will that you demand of a language.

        If you indent your C, PHP, Java, or whatever else sanely, then you will have no issues with Python indentation rules. They are just the sane C rules, but enforced.

  • by geminidomino (614729) on Thursday July 31, 2014 @02:40PM (#47576029) Journal

    I wonder if my favorite bug/misfeature will make the cut and be enshrined forever, because it's *fun* when a successful database instruction throws an exception.

  • by NoNonAlphaCharsHere (2201864) on Thursday July 31, 2014 @02:42PM (#47576037)
    Unfortunately, it's written in PHP, so there's some disagreement about WHAT is says.
  • by goodmanj (234846) on Thursday July 31, 2014 @03:56PM (#47576737)

    PHP Formal Specification:

    1) Don't use PHP.

    • by lgw (121541) on Thursday July 31, 2014 @08:25PM (#47578545) Journal

      PHP Formal Specification:

      1) Don't use PHP.

      No wonder you're getting modded down if you think that's a formal specification! C'mon:


      1. Abstract.

      Don't use PHP.

      2. Conventions used in this document.

      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
      document are to be interpreted as described in RFC-2119

      3. Normative Guidance for the Use of PHP

      One MUST NOT use PHP.

  • I formally specify PHP to be crap!

Get hold of portable property. -- Charles Dickens, "Great Expectations"

Working...