Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

PHP Finally Getting a Formal Specification

timothy posted about 2 months ago | from the let-the-ossification-ceremony-commence dept.

PHP 180

itwbennett (1594911) writes "Despite becoming one of the most widely used programming languages on the Web, PHP didn't have a formal specification — until now. Facebook engineer and PHP core contributor Sara Golemon announced the initiative at OSCON earlier this month, and an initial draft of the specification was posted Wednesday on GitHub."

cancel ×

180 comments

Sorry! There are no comments related to the filter you selected.

LOL (-1)

Anonymous Coward | about 2 months ago | (#47575815)

I hear Timmy tosses a mean salad.

That's a hard road to take (-1)

Anonymous Coward | about 2 months ago | (#47575821)

May the total and complete absence of a god bless her entirely fictional soul.

Formal specifications are pretty useless for this (0)

gweihir (88907) | about 2 months ago | (#47575887)

First, almost nobody can read a formal language specification with any reasonable degree of fluency. And second, an informal (but exact) specification does a much better job.

Re:Formal specifications are pretty useless for th (-1)

Anonymous Coward | about 2 months ago | (#47575901)

Can I furiously plunge my veiny, throbbing dick up your poop shoot?

Re:Formal specifications are pretty useless for th (-1, Offtopic)

ArcadeMan (2766669) | about 2 months ago | (#47576027)

Poop shoot specification marked exit only, access denied.

Re:Formal specifications are pretty useless for th (-1)

Anonymous Coward | about 2 months ago | (#47576077)

That's not what he told the dudes at the glory hole last night.

Why was this modded down? (-1)

Anonymous Coward | about 2 months ago | (#47576213)

Homophobic mods.

Re:Why was this modded down? (-1)

Anonymous Coward | about 2 months ago | (#47579185)

No, it's because only a retard confuses "shoot" with "chute."

Re:Formal specifications are pretty useless for th (1)

Anonymous Coward | about 2 months ago | (#47575905)

Does an informal (but exact) specification "set[] the stage for additional implementations of the language"?

Re:Formal specifications are pretty useless for th (2)

gweihir (88907) | about 2 months ago | (#47575919)

Yes, very much so. Most languages do not have formal specifications.

Re:Formal specifications are pretty useless for th (2)

gweihir (88907) | about 2 months ago | (#47575941)

I should also add that what they are doing is at best a "semi-formal specification". Still pretty clunky.

Re:Formal specifications are pretty useless for th (1)

Bacon Bits (926911) | about 2 months ago | (#47575965)

I should also add that what they are doing is at best a "semi-formal specification". Still pretty clunky.

That seems appropriate considering the topic.

Re:Formal specifications are pretty useless for th (1)

Anonymous Coward | about 2 months ago | (#47576419)

Yes, very much so. Most languages do not have formal specifications.

Both C and C++ have formal specifications, and they are more or less the most languages that people use. Objective-C does not have a specification but it's mostly C anyway. Not sure about Java and C# but I think they have specs too. That pretty much covers everything.

Re:Formal specifications are pretty useless for th (2)

rockmuelle (575982) | about 2 months ago | (#47576703)

Actually, neither C nor C++ have formal specifications. They both have very well defined and curated standards documents that can be called specifications (without the formal part), but neither has a proper formal specification.

-Chris

Re: Formal specifications are pretty useless for t (0)

Anonymous Coward | about 2 months ago | (#47577363)

That is technically correct but completely irrelevant in practice. It gets the same job done anyway.

Re:Formal specifications are pretty useless for th (1)

lgw (121541) | about 2 months ago | (#47578489)

What bizarre notion of "formal standard" are you holding on to that would exclude the C standard? It has a formal standardization process complying with the requirements for ISO/IEC publication.

An informal standard is "what some guy wrote", like the K&R C book (which really was used as a standard by compiler writers before the formal standard, and worked well enough for a while).

Re:Formal specifications are pretty useless for th (4, Informative)

gweihir (88907) | about 2 months ago | (#47578873)

A formal specification is a specification done in a formal specification language. There is no other meaning of that term. The people claiming they are doing a "formal" specification likely confused this with "exact". These two concepts are orthogonal. A formal specification can be inexact (or even unsound), while an informal specification can be exact (and sound).

A "formal standard" is something else, it usually refers to a more-or-less exact and complete _informal_ specification that is uniquely identified by its designation. The main difference is that in theory, you could check a formal specification for soundness using an automated theorem prover. Or you could automatically generate a compiler from it. An informal (but possibly exact) specification does not allow that, as it needs a human in the loop.

Re:Formal specifications are pretty useless for th (1)

squiggleslash (241428) | about 2 months ago | (#47578837)

Unless we're using "formal specification" in a form uncommonly known in the English language, ANSI C (hint hint) does, indeed, have a formal specification or three.

In fact, that's part of the problem with C. ANSI spent a lot of time trying to make their specification so generic it could be implemented on all kinds of different hardware, leaving us with a language that means virtually every bit of "obvious what it does" readable code can be re-interpreted by every optimizing compiler to mean something completely different. A big problem, considering C's system programming roots.

Re:Formal specifications are pretty useless for th (1)

gweihir (88907) | about 2 months ago | (#47578879)

That is not possible. The English language is not a formal specification language and hence does not allow the creation of formal specifications using it. ANSI C does not have a formal specification.

Re:Formal specifications are pretty useless for th (1)

gweihir (88907) | about 2 months ago | (#47578855)

You cannot do formal specifications that way. A formal specification must always be done in a formal specification language, or it is not a formal specification. As I have pointed out, you can do exact non-formal specifications and that is what C and C++ have.

Re:Formal specifications are pretty useless for th (0)

Anonymous Coward | about 2 months ago | (#47575991)

Yes, but I think anybody clean-rooming PHP from spec would have quite an uphill battle getting anybody to use it. I guess it would come in handy if the original fork started doing something that some members of the community found objectionable. I think there would be some alternatives floating around even without a spec; but I'm not in that community and thus not aware. What say? Are there PHP clones floating around already? Even as a hobby?

Re:Formal specifications are pretty useless for th (5, Informative)

Tailhook (98486) | about 2 months ago | (#47576073)

Yes, which is probably why this is coming from a Facebook engineer. PHP is pretty central to Facebook and Facebook has been re-implementing PHP for many years now. Facebook created a PHP to C++ translator (HPHPc) which has since been deprecated in favor of a new PHP virtual machine; HHVM. So Naturally formalizing PHP is of great interest to Facebook.

Re:Formal specifications are pretty useless for th (3)

CrashNBrn (1143981) | about 2 months ago | (#47577147)

Also, Hack:a new (Open Source) programming language for HHVM [facebook.com]

Hack, a programming language developed for HHVM that interoperates seamlessly with PHP.
Hack reconciles the fast development cycle of PHP with the discipline provided by static typing, while adding many features commonly found in other modern programming languages.

An open source version of Hack is available at http://hacklang.org/ [hacklang.org] as part of the HHVM runtime platform, which supports both Hack and PHP.

Also, FBIDE (a web-based Hack development environment) was presented at Facebook's Hack Developer Day [facebook.com] ,

Joel B. and I introduced Facebook's web-based Hack development environment, known internally as âoeFBIDE.â The Hack type checker is compiled to JavaScript, so all Hack language checking is done very fast, client-side. Features of FBIDE include autocomplete, an integrated debugger, quick file and code search, and other pretty cool things. FBIDE has been a great success internally at Facebook. At a company where vim and emacs are the dominant choices for development, a large percentage of Facebook engineers are using FBIDE, and the number is growing quickly. We believe FBIDE will be useful to Hack developers outside of Facebook, allowing them to productively become familiar with the language, so we're working on plans to make it more widely available â" hopefully toward the end of summer 2014.

Re:Formal specifications are pretty useless for th (2, Insightful)

Anonymous Coward | about 2 months ago | (#47575927)

Not really.
If you don't have a formal specification and you have two implementations that do different things, there is no way to know which is correct.
Besides, not having a specification is what led to PHP being such an ad-hoc mess in the first place.

Re:Formal specifications are pretty useless for th (1)

Dogtanian (588974) | about 2 months ago | (#47576105)

Besides, not having a specification is what led to PHP being such an ad-hoc mess in the first place.

Yeah, but unfortunately it's *way* to late in the day to avoid having to retain (and, ironically, formalise) the ad-hoc mess without breaking countless existing programs.

The most notorious example being one of the simplest, but also the most obviously naff; the fact that the ternary "?:" operator has incorrect precedence in PHP (compared to every other C-derived-syntax language). This quite obviously *was* a fsck-up early on (IIRC they said as much), but will always have to be kept in, an unwelcome reminder of PHP's amateur, ad-hoc origins that'll look bad to anyone learning the language, regardless of how well it improves in other areas.

A clean break is needed, like "Visual Fred" (1)

tepples (727027) | about 2 months ago | (#47576171)

Then perhaps a clean break is needed between the "old language" and the "new language". It can be done like Visual Basic from VB 6 to VB.NET or Python 2.6 to Python 3, where modules in the old language first need to be translated to the new. Or it can be done with two side-by-side parser frontends, allowing a module written in one language to be include_once'd in a module written in the other.

Re:A clean break is needed, like "Visual Fred" (1)

Dogtanian (588974) | about 2 months ago | (#47576505)

Which would significantly reduce the appeal of the "new language" and probably result in people continuing to use the old version- with masses of support, extensions, accumulated wisdom, and software already built on it- probably forking it at some point if the current owners tried to force the change through.

Let's be honest; VB.Net was a good example of one that *didn't* succeed. It was very different to VB6, effectively a whole new environment and tech tied together with a similarly-syntaxed language, and it never achieved the popularity of its predecessor.

Yes, MS may have forced many to move to .Net by making clear that VB6 and its related infrastructure was obsolescent, but that translated to C# use, not VB. Presumably people either remained with VB6 and those who used .Net were either newcomers who had no need of a legacy language (*) or VB6 users who decided that C# was a more sensible choice (since it was clearly MS's favoured language for .Net, and wasn't hobbled by syntax that was effectively a comfort-blanket holdover from 8-bit home computer BASICs).

(*) I'm guessing that classic VB gained its userbase from the generation (and group) who started with "old school" 8-bit BASICs, and found its syntax accessible, then were able to grow while their "BASIC" grew in capability. Thing is, if you didn't start or grow with VB, then what it became is no simpler or easier to learn than C-influenced syntax like C# (and I'm speaking as someone who *did* use old-school BASIC as my first language, but not VB, and I'd much rather use a C-style language).

Re:A clean break is needed, like "Visual Fred" (0)

Anonymous Coward | about 2 months ago | (#47576647)

(*) I'm guessing that classic VB gained its userbase from the generation (and group) who started with "old school" 8-bit BASICs, and found its syntax accessible, then were able to grow while their "BASIC" grew in capability. Thing is, if you didn't start or grow with VB, then what it became is no simpler or easier to learn than C-influenced syntax like C# (and I'm speaking as someone who *did* use old-school BASIC as my first language, but not VB, and I'd much rather use a C-style language).

The appeal of classic VB had little to do with the language itself - it was all about the dev environment. Remember this was the early days of GUIs, and VB was hands down one of the easiest ways to build forms-over-data style applications. Slap down some buttons, drop a data grid, hook up a database connection, done. Write a little bit of code (in a fairly kind to beginners syntax) and you're off to the races. Between that and the absolutely huge component market, it was very easy to get small apps built.

Re:A clean break is needed, like "Visual Fred" (0)

Anonymous Coward | about a month ago | (#47578179)

Then perhaps a clean break is needed between the "old language" and the "new language"...like...Python 2.6 to Python 3

Hahaha, oh yeah, how's that working out? Oh! Or like Perl 5 to Perl 6!

Re:A clean break is needed, like "Visual Fred" (1)

tepples (727027) | about 2 months ago | (#47578991)

If you're trying to imply "still nothing uses Python 3", the version of Blender on my PC embeds Python 3. One big problem (doing the right thing with side-by-side Python 2 and 3 on Windows) was solved when Python 3.3 implemented PEP 397 [python.org] .

Re:A clean break is needed, like "Visual Fred" (1)

exploder (196936) | about 2 months ago | (#47578995)

Not all that well in Python's case, but if 2.6 sucked as bad as PHP does now, there might be more urgency. And Perl 6 might get a bit more traction when and if it starts existing.

Re:Formal specifications are pretty useless for th (1)

Anonymous Coward | about a month ago | (#47578321)

Besides, not having a specification is what led to PHP being such an ad-hoc mess in the first place.

Yeah, but unfortunately it's *way* to late in the day to avoid having to retain (and, ironically, formalise) the ad-hoc mess without breaking countless existing programs.

So? PHP has done that before. Just add a flag in the configuration to emulate the old incorrect behavior like they did with register_globals.
Those who uses the old syntax can just set the flag until they have fixed their code. Then the option can be removed in a couple of years.

PHP doesn't have a formal specification yet so it is not like those who use it can expect their code not to break with an update anyway.

Re:Formal specifications are pretty useless for th (1)

gweihir (88907) | about 2 months ago | (#47578889)

That is BS. In order to create a second implementation, you need an _exact_ specification. It being a formal specification is completely optional.

Re:Formal specifications are pretty useless for th (4, Informative)

Daniel Hoffmann (2902427) | about 2 months ago | (#47576309)

A formal specification is useful for the implementers of the languages to guarantee that your code runs the same across all implementations. It is pretty important. It should define all use cases possible and highlighting the "undefined" use cases.

Re:Formal specifications are pretty useless for th (1)

gweihir (88907) | about 2 months ago | (#47578893)

BS. A formal specification is needed if you want to use automated theorem proving to prove properties of the language or if you want to generate compilers automatically. For specifying how an implementation works, you need an exact specification, but that can well be (and usually is) an informal one.

Come on people, does nobody know basic CS terms anymore?

Re:Formal specifications are pretty useless for th (1)

narcc (412956) | about 2 months ago | (#47579045)

This is Slashdot so ... probably not.

Re:Formal specifications are pretty useless for th (1)

Chris Mattern (191822) | about a month ago | (#47577869)

Formal language specification isn't meant to be perused with a cup of coffee in one hand. It's primary purpose is that you can use it to prove that your implementation of the language does what the language specs say it's supposed to do. Your "informal (but exact) specification" doesn't do "a much better job" at that. It can't do that job at all.

Re:Formal specifications are pretty useless for th (1)

gweihir (88907) | about 2 months ago | (#47578909)

Oh? And which language implementations do you know that actually have such a proof? For real world languages and implementation, the number is likely "zero" as most languages do not have a formal specification that could be used as starting point in the first place.

And here is one more hint from the real world: Nobody proves compiler correctness using formal methods for real languages, because nobody can pay the huge amount of money that would cost or wait the few decades it would take. Instead there is this thing called "testing".

Re:Formal specifications are pretty useless for th (1)

Mister Liberty (769145) | about a month ago | (#47578339)

The point, as I see it, is: what with the mess PHP was (and is [sorry I remain scpetical]), it must have been a humbling,
and as such deserving, experience on the part of the PHP developers. Let's see where that leads to.
As I used to say: you can do great things in PHP in spite of PHP. In that regard, the language is unique.

Re:Formal specifications are pretty useless for th (1)

Urkki (668283) | about 2 months ago | (#47579363)

an informal (but exact) specification does a much better job.

Informal and exact are mutually exclusive, pretty much by definition.

its why devs cringe. (3, Insightful)

nimbius (983462) | about 2 months ago | (#47575953)

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.

Re:its why devs cringe. (0)

Anonymous Coward | about 2 months ago | (#47576185)

A formal specification might have prevented PHP from turning out the way it did, but it won't fix any of PHP's problems. PHP cannot be fixed without designing a new language from scratch, but do we really need yet another language at this point? Especially one thought up by the people behind PHP? I'll pass, thank you.

What PHP needs isn't a specification - what it needs is an exodus.

Re:its why devs cringe. (4, Insightful)

OzPeter (195038) | about 2 months ago | (#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.

Re:its why devs cringe. (1)

Bacon Bits (926911) | about 2 months ago | (#47576415)

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.

Re:its why devs cringe. (1)

Anonymous Coward | about 2 months ago | (#47576583)

We live in a world with enough languages that pure technical constraints are unlikely to limit you to a single language.

Good syntax is a huge part of readability, which is a huge part of maintainability. Of course, the argument that Python's syntax is harder to read is pretty mad - it utilisies the very thing that we do in other languages where it isn't necessary to make our code clear.

Factors that force choice of language (1)

tepples (727027) | about 2 months ago | (#47576835)

We live in a world with enough languages that pure technical constraints are unlikely to limit you to a single language.

But there are more than enough political constraints on developers to force their language choice. For example, Windows Phone 7 and Xbox Live Indie Games platforms could run only verifiably type-safe, .NET CF-compatible CIL, which in practice meant C#. In the applet era, you needed a language that compiled to JVM bytecode. In the Flash era, you needed a language that compiled to AS3 bytecode. Nowadays, the client side of a web app needs to be in JavaScript. And for a long time, entry level web hosting with PHP was cheaper per year than hosting with other server-side languages.

Re:its why devs cringe. (1)

narcc (412956) | about 2 months ago | (#47579101)

- it utilisies the very thing that we do in other languages where it isn't necessary to make our code clear.

Except it imposes a burden on the developer, which, in sane languages, can be handled with a single click on the the pretty-print button.

This argument drives me crazy. It completely ignores *every other factor* that affects code legibility. I've even seen Python zealots argue that all Python code readable because indentation is enforced. What a joke! I've seen plenty of illegible Python code.

And yes, when the indentation level changes by more than one level, it's significantly more difficult to read than other languages. Even if you disagree, you've got to admit that it's far easier to tell when a block begins and ends when you have two indicators instead of one.

If that's not to your liking, consider that, in Python, it's possible to have two programs that appear visually identical but are, in fact, different. You want to talk about readability while advocating a language in which you can easily create errors that you actually can't see? It's the height of absurdity.

Re:its why devs cringe. (0)

Anonymous Coward | about 2 months ago | (#47576531)

Python does do a lot of memory things behind the scenes that are not terribly efficient, which does make it hard to use for big/long running programs.

However, Python did break with a lot of bad habits in the transition from 2.7 to 3.0, using generators by default for things like range(), items(), etc. makes programming it efficiently much easier than before (xrange() and iteritems() just don't roll off the fingers in the same way, even if they should be used instead).

As for whitespace, it is there for the person reading the code*, not for those writing it. It forces visual delineation of structures, which is VERY handy when reading.

* remember this person is likely to be one-year-older-you, so you do kinda care about this person.

Re:its why devs cringe. (0)

Anonymous Coward | about 2 months ago | (#47576547)

The list is minimal in comparison. PHP is basically an example of what not to do in language design, probably worse than JavaScript. It's got a huge amount of cruft from older times, terrible "features" and horrible ideas. I mean, hell, if you can think of a single good reason PHP has both 'and' and '&&' operators, that are both logical ands, but have different operator presedence, please let me know. It's maddeningly bad.

Python, on the other hand, is one of the best designed languages around today - probably only matched by the likes of D. It has a rich featureset without having a glut of useless features, a clear and well thought out syntax and style, and a strong standard library. Better yet, they haven't been afraid to go back and fix issues in the language.

To say 'it has it's own issues' is a truth, but one without a shred of relevance. Walking and riding a space shuttle are both methods of transport, if I want to go to the moon, my feet are not a viable.

As to 'I want the computer to bend to my will' - that's exactly what Python does. In every other language you have to put in braces to make it easier for the parser to understand you, in Python, you avoid that duplication (if you don't correctly indent your code, you are a madman) - the computer does the work so you don't have to.

Re:its why devs cringe. (1)

Vanders (110092) | about a month ago | (#47578279)

In every other language you have to put in braces to make it easier for the parser to understand you

...in Python you have to put in whitespace to make it easier for the parser to understand you.

Advantage: none.

Re:its why devs cringe. (1)

rdnetto (955205) | about a month ago | (#47577967)

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.

Re:its why devs cringe. (2)

ShadowRangerRIT (1301549) | about a month ago | (#47578213)

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 costs are basically nil, you just have the issue of page faulting due to "random" access into the hash table (and Python at least optimizes for that case; the collision chaining algorithm in recent versions of Python tries to chain into the same cache line if it can, alternating with chains by "long steps" to avoid issues with consecutive hash codes).

Stuff that kills Python performance includes: Minimal optimization of code by the byte code compiler, and none by the byte code interpreter (while each hash table lookup is cheap, a loop will perform it over and over again, even if you're accessing the same attribute on the same object, because the compiler and interpreter aren't sophisticated enough to recognize what's happening); inability to parallelize CPU bound tasks using threads thanks to the GIL; lack of "primitive" types, so even basic math involves substantial memory allocator overhead and memory fragmentation, etc.

TL;DR: Python's performance problems aren't primarily a result of hash tables.

Re:its why devs cringe. (0)

Anonymous Coward | about a month ago | (#47578245)

Python was around before PHP was even a twinkle in anybody's eye. It didn't learn anything from PHP.

Anybody who has used languages like Lua understand the severe limitations to Python. Lua is what Python would look like if Python was done properly (setting aside the issue of indentation). Python's greatest asset is its popularity. That's reflected in the fact that people keep citing projects rather than unique features of the language. But in the real world popularity is one of the most important assets of a language.

Re:its why devs cringe. (1)

squiggleslash (241428) | about 2 months ago | (#47578819)

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

Re:its why devs cringe. (1)

narcc (412956) | about 2 months ago | (#47579079)

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.

Re:its why devs cringe. (0)

Anonymous Coward | about 2 months ago | (#47576641)

Python is two incompatible juggernauts (versions 2 and 3) trying to swallow each other, but yes that is an improvement over PHP which has broken itself more often.

Re:its why devs cringe. (0)

Anonymous Coward | about a month ago | (#47577845)

Personally I just stayed away from it because it was hilariously bad.

1 month was enough for me to never touch it again.

its why devs cringe. (1)

Anonymous Coward | about a month ago | (#47578341)

PHP is still the lingua franca of the Internet, and is a very useful langague. In fact, I like to consider it the English of the server side. JavaScript is the English of the client side. Yeah, I know, node.js.

MUTEX (0)

Anonymous Coward | about 2 months ago | (#47575987)

Hopefully near the top of the spec they outline the following mutual exclusion rule:

(PHP XOR Formal) AND (PHP XOR Specification)

PHP is going away? (0)

Anonymous Coward | about 2 months ago | (#47576023)

Remember that time (yesterday) when Dice said PHP was going away...

At last (2)

geminidomino (614729) | about 2 months ago | (#47576029)

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.

PHP Finally Getting a Formal Specification (5, Funny)

NoNonAlphaCharsHere (2201864) | about 2 months ago | (#47576037)

Unfortunately, it's written in PHP, so there's some disagreement about WHAT is says.

Re:PHP Finally Getting a Formal Specification (1)

sootman (158191) | about 2 months ago | (#47576207)

Is it "Formal Specification" or "Specification Formal"? Will the process take the form of "PHP to Formal Specification" or will it be "Formal Specification from PHP"? How about "php2spec"?

Re:PHP Finally Getting a Formal Specification (4, Funny)

NoNonAlphaCharsHere (2201864) | about 2 months ago | (#47576357)

Actually SpecificationFormal($PHP) automagically converted $PHP to Perl and returned false. No-one is sure WHY, but that's the way it works.

Re:PHP Finally Getting a Formal Specification (1)

w_dragon (1802458) | about 2 months ago | (#47577669)

It's a bug, but some people rely on the current behavior, so the next release will have RealSpecificationFormal that does more what people might expect.

Re:PHP Finally Getting a Formal Specification (1)

NoNonAlphaCharsHere (2201864) | about 2 months ago | (#47579163)

Well played. I think yours is the funniest in the thread. And tooooo true.

Re:PHP Finally Getting a Formal Specification (4, Funny)

Megane (129182) | about 2 months ago | (#47576887)

I'll just wait for them to replace php_specification() with real_php_specification() ... or is it php_real_specification() ?

Re:PHP Finally Getting a Formal Specification (0)

Anonymous Coward | about 2 months ago | (#47577473)

I smiled.

Re:PHP Finally Getting a Formal Specification (0)

Anonymous Coward | about 2 months ago | (#47577531)

I'll just wait for them to replace php_specification() with real_php_specification() ... or is it php_real_specification() ?

i thought it was php_real_specification_string()

Engineer? (0)

Anonymous Coward | about 2 months ago | (#47576081)

Facebook engineer and PHP core contributor....

My father in law in an actual engineer - BSME, patents up the wazzoo as well top secret things that I couldn't even imagine because of his work on the F-22.

As a PHP programmer (which I do not know why someone would need another title*), the next time he irritates me (which is often), I am going to refer to myself as a PHP engineer and computer scientist - thereby implying that I am smarter and better than he is.

.

....

Kids, a couple of decades ago, being a programmer had a bit of prestige.

Then we had to be called "developers" and now "engineers".

Years ago, my title was Level 3 Engineer but that was because the company (NCR) was stuck in the Stone Age and that was just the pay grade they assigned us. If janitor justified our pay in that grade, I cold have easily been called a level 3 Janitor - which would NOT bother me in the least - actually, I'd get a kick out of telling people that I was a janitor. Take your titles and shove'em! Show me the money!

Re:Engineer? (4, Informative)

OzPeter (195038) | about 2 months ago | (#47576263)

Facebook engineer and PHP core contributor....

My father in law in an actual engineer

As an actual engineer as well, this sort of inflating of titles is a peeve of mine right now. It makes job searches nigh impossible as every position out there has the word engineer in them, and all recruiters seem to be doing nowadays is matching keywords - sort I keep getting emails about 'engineer this' and 'engineer that', when they are totally irrelevant to any sort of genuine engineering position.

Re:Engineer? (1)

Megane (129182) | about 2 months ago | (#47577177)

Once I got a call from a recruiter for a circuit board assembly job... because I had "assembly language" in my resume. (And another time I got a call for an IBM 370 Assembler position because of course that's the only assembly language that has ever been invented, but at least that was somewhat less off-target.)

Anyhow, most code monkeys out there are not "software engineers", regardless of what HR calls them. They don't engineer their code so much as poop it out and throw it at each other through the bars of the cage.

Re:Engineer? (0)

Anonymous Coward | about a month ago | (#47578153)

genuine engineering position.

They're not TRUE Scottsm- Engineers, right? The actual problem here is your notion that there is such a thing as "genuine engineering."

Re:Engineer? (1)

narcc (412956) | about 2 months ago | (#47579145)

But there is!

In many places, it's illegal to engage in the practice of unlicensed engineering.

We could stand a good crack-down. I'm sick of seeing all the one-skill-wonders running around calling themselves "engineers" to feed their fragile egos. It does a serious disservices to REAL engineers, like the parent.

Re:Engineer? (1)

lgw (121541) | about 2 months ago | (#47578523)

You're not an actual engineer unless you're rolling your petard up to the castle gate! Don't give me any of this new-fangled train-driver crap. That makes job searches nigh impossible, as recruiters keep bugging be for train-driving jobs when they are totally irrelevant to any sort of genuine siege engine!

Re:Engineer? (0)

Anonymous Coward | about 2 months ago | (#47579195)

I look forward to the day when I can have my sandwiches made by Subway's sandwich engineers.

Re:Engineer? (0)

Anonymous Coward | about 2 months ago | (#47576321)

... or PHP engineer != Facebook engineer and PHP core contributor

Re:Engineer? (0)

Anonymous Coward | about 2 months ago | (#47576601)

In many states "engineer" is a protected term that requires a Professional Engineering license. Some states have PE test for civil, electrical, mechanical and software engineering. Our university has added computer engineering as a separate degree (besides computer science) which requires the same math and other engineering core classes as any other engineering major to prepare students for the PE exams. To be honest, I don't know why/how they have so many taking the computer engineering considering it's a 5 year program instead of 4, it's really hard (more math, and basic engineering courses like statics and dynamic), and few employers will see it any differently.

The practical uses of a P.E. in software are generally in high risk fields: medical imaging, DOD work, and software for flight computers. Where code needs to be stamped by a professional engineer, and code is often handed over to another company to be independently mathematically proven.

All that said, I don't know if this "PHP Engineer" is an engineer or not. I'd be really suprised if they were.

I'm waiting... (0)

Anonymous Coward | about 2 months ago | (#47576095)

...For someone to link that fractal of bad design blag. :D

Six identifiable bullet points (2)

tepples (727027) | about 2 months ago | (#47576235)

Let's play Hegelian dialectic:
Thesis
The "fractal" rant [eev.ee]
Antithesis
The "hardly" rebuttal [devshed.com]
Synthesis
Six identifiable bullet points [slashdot.org]

Re:Six identifiable bullet points (0)

Anonymous Coward | about 2 months ago | (#47577113)

Pity to see you repeat your own "six bullet points" that managed to miss most of the points made by a mile.

Re:Six identifiable bullet points (1)

tepples (727027) | about 2 months ago | (#47577237)

So what, may I ask, are your superior points?

Re:Six identifiable bullet points (1)

narcc (412956) | about 2 months ago | (#47579189)

They don't exist. I've asked the "what's wrong with it" question countless times. I've never received an actual answer. I think your six points are about spot on, that's pretty much all the article has to offer.

I disagree with the first point, for obvious reasons. As well as point 5, which is not a language issue. Point 6 would need some clarification as it's completely unsupported. Point 2 doesn't make sense to me. How many languages throw an exception on a parse error? What if the error is in the handler itself? Further, he seems to hate the fact that PHP doesn't have MORE fatal errors. I'm convinced that he'd complain, as he did in other cases, if a parse error *wasn't* fatal. It's a very odd complaint.

I'd give the author points 3, and 4. Of course, even if I grant him all six, it hardly makes PHP a "fractal" of bad design.

Re:Six identifiable bullet points (1)

Calavar (1587721) | about a month ago | (#47577847)

I've read ManiacDan's "hardly" rebuttal, and frankly speaking, it is garbage. Here is my rebuttal to the rebuttal:

Predictable - The author states that it's the language's responsibility to be understood by everyone who uses it, rather than the builder's responsibility to understand their tools.

No, that's a strawman. The the criticism is that languages should facilitate productivity by acting intuitively whenever possible. Language design is to an extent a user interface design for developers. And the number one principle of user interface design is anything that doesn't act the way the user expects it to is broken. (Just ask Joel Spolsky.)

Let's use a little analogy: When you hire an handyman to work on your house, you expect him to know his tools like the back of his hand. You have a choice of two handymen. The first owns a Python powerdrill that has three settings: slow, medium, and fast. The second owns a PHP powerdrill that has twenty-seven different modes. The first mode is very-slow- counterclockwise-drywall-pneumatic, the second mode is medium-slow-clockwise-hardwood-electric, and so on. Which handyman is going to be able to finish the product more quickly. Well, it depends. If the Python handyman doesn't know the basics of Python, he'll do much worse than PHP handyman. But if the PHP handyman and the Python handyman are both equally competent, the Python handyman will be three times faster: because the Python drill is so much simpler, the Python handyman will be able to a lot of his work purely on instinct, but the PHP handyman will have to employ his full cognitive capacity even for the simplest tasks.

Consistent

ManiacDan concedes this point, so I won't write on it here.

Concise - He makes statements about "boilerplate" a number of times, but never defines the term or tells us what he's talking about. PHP is very concise. It includes time-saving functions like usort(), file_get_contents(), and other functions which in C++ would take pages of code.

I am a diehard C++ fan, but even I'll admit that calling a language "concise" because it's less verbose than C++ is laughable. Would you call a slug a sprinter because it is faster than a snail? I mean seriously, what is this nonsense? A language is concise because it has a built in sort function? I could write a sort function in assembler and reuse it in all my subsequent programs, but that doesn't make assembler concise. You want something concise? How about something like Python's list comprehensions? How about a null-coalescing operator a-la C# or Ruby? How about using Ruby style blocks for iterating and callbacks? How about C++-style RAII or Java-style "finally" for avoiding tons of if-else statements to release resources after an exception?

He lists error-checking as boilerplate. I don't know how Python handles it, but generally as a programmer I'd like to know if a file operation failed.

Oh, now it makes sense. The only way someone would defend the mire of if-elseif-else error checking in PHP would be if they were ignorant of a better way.

Reliable - This, again, is him assuming that it's the language's responsibility to be understood, rather than his responsibility to understand it. He goes into what he considers "gotcha" events later in the article, but (spoiler alert) they all stem from his fundamental understanding of the language.

No, ManiacDan, he understands the == statement perfectly, as you can tell from his meticulous list of instances when == is not transitive. In fact, he understands it so well that he knows that it is complete BS. A web language needs an eye for security, but only in the mother of all of web-languages PHP can you compare two password hashes using "==" and have the result be "true" even if the hashes are different. But we should use "===", you say! Great. Now tell me how easy it is to have an "==" mixed up with an "==" somewhere a hundred thousands lines of code. And this is on top of the "="/"==" mixups that are already prevalent in many C-style languages.

Debuggable - Now this I'll give him. PHP's error handling is atrocious. I mean, look at the errors some of these new users are getting on DevShed.

I'm starting to wonder if ManiacDan even knows what a debugger is. I'll give him the benefit of the doubt though. Yes, PHP's error messages are atrocious.

Arguments - However, it is his responsibility to come to an understanding of how programming languages work, and he has failed to do so. He also uses a wonderful straw man with "you should just use C if PHP handles 5% of its operations the way C does." Just because fopen returns false in C and in PHP doesn't mean PHP is a net loss. Finally, his argument of "the largest and most popular websites in the world, designed and written by the smartest programmers in the world, don't prove anything" is laughable.

Again with the claims that Eevee is a PHP novice. He isn't. He wouldn't have been able to come up with a list of a hundred problems with a language (many of which, like the ternary operator precedence issue, are extremely subtle) if he barely understood how it works. And no, PHP is not a good language simply because it is used by Facebook, Wikipedia, et al. The first iteration of the software for DaVinci surgical robot was written in Matlab. DaVinci became the gold standard in surgical robotics. Does this mean Matlab is the best language for surgical robotics? Absolutely not! Latency is a huge issue in robotics, and Matlab, an interpreted, garbage collected language, had huge issues with latency. Intuitive Surgical struggled with the Matlab software for quite a while before they rewrote most of it in C++. Facebook has already migrated much of its codebase to Hack (which is basically their cleaned up version of PHP) and C++.

Philosophy - PHP was designed to be easy to understand, because at the time the thought of full-featured web applications was silly. An item's source doesn't discredit what it's become. What if someone told you "America was founded to be a colony (and, reading between the lines, not a country); it has not well escaped its roots. This is why I believe nobody should take America seriously as a country." Stupid, right? Good, glad we agree.

Once again, ManiacDan completely misses Eevee's point. PHP was designed to be easy to understand, but it isn't. How can a language in which understanding even the equality operator requires a table of casting precedences be considered "easy to understand"? The issue for PHP isn't that it is used by novices or that it was designed for novices. The problem is that it was designed by novices. Language design is hard. Language design is easy to screw up. The legacy of PHP will remain an immortal reminder of this.

PHP is built to keep chugging along at all costs. MY GOD! HOW LUDICROUS! PHP is a web language with very little ability to recover from a crash the way you would in a desktop environment.

My god. It scares me that a web developer would believe this. WEB DEVELOPMENT IS ABOUT SECURITY. It is much better to have your web app throw an exception, crash, reboot, and serve a 500 message to the user (like a Django or Rails app) than it is to have "it continue chugging along" doing all kinds of undefined things to your server. PHP is a hacker's fantasy land precisely because it continues chugging along.

This is the closest he comes to outright saying "I don't understand it and therefore it's wrong." If you want to understand how weak typing conversions work, you could look in the manual for the chart, or you could read my article on it.

Again, if you have to consult a chart every time you want to use the equality operator, there is something fundamentally wrong with the operator. Remember the handyman with the PHP powerdrill? Well apparently he has to consult an almanac every time he's about to drill a hole. If the moon is waxing, he sets his drill to very-slow-counterclockwise-drywall-electric. If the moon is waning he sticks the drill to his head and puts himself out of his misery.

Server-level configurations are pretty handy and remove a lot of boilerplate, don't you think? Good thing removing boilerplate was one of his biggest criteria back at the beginning.

Server level configurations are useful if they define things like the maximum number of concurrent database connections or header size limits. They aren't useful when they completely mutate the way the language works. When you can't tell what "fopen('http://www.google.com', 'r')" is going to do with out opening up php.ini, .htaccess, and scanning your entire codebase for calls to ini_set, that is a problem. It gets worse when you realize that different libraries are written with different php.ini settings. What do you do when library A cannot run with the php.ini that library B requires? Do you roll your own version of library A? Not a single other language I know has this problem.

C and Python crash fatally, potentially destroying the memory space of other programs. Got it.

Again, ManaicDanhas zero idea what he his talking about. The C application might crash, but assuming that it running on any operating system written after 1995, it will not destroy the memory space of another program. That's exactly what segfault means: the program was prevented from destroying another program's memory space. Again, segfaulting the CGI process and having the server deliver a 500 message to the user is better than chugging along with undefined behavior. As for a Python exception destroying other programs' memory space... Oh I give up.

We're barely halfway through ManiacDan's post and already nearly point he's raised was one of the following:

1. A misunderstanding or intentional misrepresentation of Eevee's criticisms. (A good language should be intuitive easy to understand get's transformed into it's the language's responsiblity to be understood by everyone.)
2. A misunderstanding of standard web development or programming paradigms. (Unhandled exceptions in a web app are bad!)
3. A failure to see the potential for problems in certain PHP features. (The configuration nightmare that is php.ini.)
4. A complete lack of knowledge of how things are done outside the confines of PHP. (The finally statement in Java or Python.)

Is there any point in continuing this exercise? ManiacDan's article is complete bunk. It's not even 1/10th as well researched as Eevee's "fractal" article. PHP sucks. Either deal with it or move to a new language.

Re:Six identifiable bullet points (1)

narcc (412956) | about 2 months ago | (#47579205)

, as you can tell from his meticulous list of instances when == is not transitive.

Which highlights his laughable ignorance. He clearly doesn't understand dynamic languages. If you do the same comparisons in other dynamic languages, or others with the relevant type casts, you'll get the exact same results.

Then again, I'm not trying to defend a long-debunked meme. I appreciate the effort you put in to your "rebuttal", but it's laughably incompetent. A bit like the "fractal" article itself.

A proof that nobody gives a shit about formal spec (2)

osiaq (2495684) | about 2 months ago | (#47576109)

Php is a king of the web without those crap titles, full stop, end of story

How did we get along for so many years without it? (0)

Anonymous Coward | about 2 months ago | (#47576165)

Will this change anything?

Re:How did we get along for so many years without (1)

ChipMonk (711367) | about 2 months ago | (#47576231)

Sure, the security holes will be part of the spec instead of mere reckless fsck-ups.

Re:How did we get along for so many years without (2)

ruir (2709173) | about 2 months ago | (#47576447)

Maybe, maybe not. Will we have now a PHP compiler to binary code?

Why binary? (1)

tepples (727027) | about 2 months ago | (#47576907)

What technical benefit does binary code have that a JIT engine lacks, other than perhaps the ability to run in obsessively locked down W^X environments that prohibit runtime generation of executable code?

Re:Why binary? (0)

Anonymous Coward | about 2 months ago | (#47577595)

What technical benefit does binary code have that a JIT engine lacks, other than perhaps the ability to run in obsessively locked down W^X environments that prohibit runtime generation of executable code?

Latency. If your JIT re-compiles source on each page load, then you add latency to the process of generating the web page.

Re:Why binary? (0)

Anonymous Coward | about a month ago | (#47577745)

lrn2fastcgi

Latency of spawning a new process for every page load makes JIT compilation delay look completely insignificant.

And if you don't respawn it incessantly, JIT will keep its caches nicely.

thus someone useless got a name (0)

Anonymous Coward | about 2 months ago | (#47576519)

as if this was the only interesting matter missing with php.

Full specification text: (2, Insightful)

goodmanj (234846) | about 2 months ago | (#47576737)

PHP Formal Specification:

1) Don't use PHP.

Existing app (0)

tepples (727027) | about 2 months ago | (#47576879)

What's the common way to transition an existing PHP app off PHP?

Re:Existing app (2, Funny)

Zero__Kelvin (151819) | about 2 months ago | (#47577233)

Reimplementation, or more accurately, implementing it properly for the first time.

Re:Existing app (1)

goodmanj (234846) | about a month ago | (#47577737)

Bitter tears of regret.

Re:Existing app (0)

Anonymous Coward | about a month ago | (#47578383)

Stop maintaining it and wait for it to become obsolete. Then burn the server.

Full specification text: (0)

Anonymous Coward | about 2 months ago | (#47578433)

Haters gonna hate. There is a ton of high quality software written in the language. Plus beginners are able to produce basic code quickly, and then learn how to be professionals. Many other languages have steep learning curves that put many people off rom the start. Looked at erlang lately?

Re:Full specification text: (4, Funny)

lgw (121541) | about 2 months ago | (#47578545)

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.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?