PHP Finally Getting a Formal Specification

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

Comments

Re:Formal specifications are pretty useless for th

[Anonymous Coward]

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

Re:Formal specifications are pretty useless for th

[gweihir]

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

Re:Formal specifications are pretty useless for th

[Anonymous Coward]

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

[gweihir]

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

its why devs cringe.

[nimbius]

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.

[OzPeter]

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.

[Bacon Bits]

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.

[Anonymous Coward]

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.

Re:its why devs cringe.

[rdnetto]

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.

[ShadowRangerRIT]

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.

[Vanders]

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.

[squiggleslash]

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.

[narcc]

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.

[narcc]

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

[tlhIngan]

* 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 braces go on a line - by not having any since the indenting already implies the braces.

The only trouble points is when more than one developer edits the file. But then again, you've already pre-decided on whether you use spaces or tabs beforehand, didn't you?

Re:its why devs cringe.

[the_arrow]

Of course it's possible to write illegible code in Python. After all, it is possible to write FORTRAN in any language.

Re:its why devs cringe.

[angel'o'sphere]

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

Re:its why devs cringe.

[angel'o'sphere]

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

Re:its why devs cringe.

[macson_g]

Want static typing? Use Cython.

Re:its why devs cringe.

[brantondaveperson]

The whole semantic-whitespace thing in Python is genius if you think about it. I mean, it's horrible - awful to use, makes a hash of copy&paste and makes emailing code around (which I guess is a bad idea but anyway) impossible. BUT, and this is the genius part, one of the endless will-never-be-settled arguments that programmers love to have is the one about indentation. If you build a position on this argument actually into the syntax of the language, then the language will always be part of the argument and thus will always be talked about. And thus always popular.

Prior to Python I would have thought that such an achievement would be impossible, but the genius of actually making *whitespace* part of the language definition pulled it off.

Genuis truly is the only word for it.

Re:its why devs cringe.

[squiggleslash]

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 squiggy! The associative array is obviously using hashtables and the other is typed!", that's... not (quite) the case. If PHP is optimizing anything with objects at some level, it's certainly not doing so based upon "static-after-parsing-app" set of possible member names: you can convert each to the other form with a simple cast, and you $some_array[$expression] has an object equivalent of $some_object->{$expression}. If it isn't using hashtables for objects too, then it's probably doing something even more braindead.

Re:its why devs cringe.

[jambox]

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 written in pure Python so you can read it's code, step through it with a debugger. If you want it to go faster you can swap it out for cElementTree, which has the same API but is compiled from C code.

Re:its why devs cringe.

[narcc]

Imagine, if you will, a mix of tabs and spaces that place two lines the same distance from the left-margin, yet, to Python, are at different indentation levels.

Visually identical means exactly that -- no visible distinction between the two programs. Take two screen-shots, they'll be identical down to the pixel.

Not 'similar'. Not 'really really close'. Identical.

It's not something you can defend. Which is funny, considering that it's not even the worst problem caused by Python's absurd use of whitespace.

Re:its why devs cringe.

[dotancohen]

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.

Re:its why devs cringe.

[hobarrera]

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.

The same can be said about C: if forces you to declare variables, and bend to the computers will (and not the other way around). This is true for any language. You merely chose to critize one about that, and let it slide for the rest.

Re:Formal specifications are pretty useless for th

[Bacon Bits]

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.

At last

[geminidomino]

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

[NoNonAlphaCharsHere]

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

Re:PHP Finally Getting a Formal Specification

[sootman]

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

[NoNonAlphaCharsHere]

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

[Megane]

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

[w_dragon]

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

[NoNonAlphaCharsHere]

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

Re:PHP Finally Getting a Formal Specification

[larpon]

Get it via file_get_contents()!

Re:Formal specifications are pretty useless for th

[Tailhook]

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

[Dogtanian]

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 proof that nobody gives a shit about formal spec

[osiaq]

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

A clean break is needed, like "Visual Fred"

[tepples]

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"

[Dogtanian]

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"

[tepples]

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.

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

[exploder]

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:How did we get along for so many years without

[ChipMonk]

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

Six identifiable bullet points

[tepples]

Let's play Hegelian dialectic: Thesis The "fractal" rant Antithesis The "hardly" rebuttal Synthesis Six identifiable bullet points

Re:Six identifiable bullet points

[tepples]

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

Re:Six identifiable bullet points

[Calavar]

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 h

Re:Six identifiable bullet points

[narcc]

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

[narcc]

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

Re:Six identifiable bullet points

[Patman64]

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

He clearly doesn't understand dynamic languages? Have you ever used a sane one like Python?

Guess what happens when you compare different types (like a string and an integer) in Python? It's fucking false because they aren't the same! Amazing! Things that aren't even the same type aren't equal! No voodoo type-magic, no charts, just the language working like you would expect.

Hm, looks like Ruby works the same way too. Oh and Lua too! What were you saying about "not understanding dynamic languages"? Have you used anything besides PHP and Javascript?

Re:Six identifiable bullet points

[tepples]

No way to turn off the language's loosely-typed comparisons.

I disagree with the first point, for obvious reasons.

True, there's a strict counterpart to ==, namely ===. But what's the strict counterpart to < or switch?

PHP allows the server operator to change program semantics in ways that are annoying to work around, such as not allowing a shared hosting subscriber to turn off "magic quotes" or not following HTTP redirects in libcurl.

[This] is not a language issue.

In PHP, if you write a program, how can you be sure that it will work as intended with whatever combination of php.ini settings happens to be in effect on the server on which you deploy the program? For example, if I use the LightOpenID library to authenticate users on a server that has open_basedir set, attempts to authenticate users coming from Yahoo! will fail because Yahoo! implements OpenID with an HTTP redirect and for some inscrutable reason, libcurl refuses to follow HTTP redirects if open_basedir is set.

PHP versions change the semantics of existing programs in ways that encourage shared hosting providers to continue to offer only outdated versions of PHP, making it impossible for web application developers to take advantage of new features.

[This] would need some clarification as it's completely unsupported.

With the MySQLi extension, the only way to bind a variable number of arguments to a prepared statement is by passing an array of references to the statement's bind_param() method using call_user_func_array(). The way this has to be done changed in PHP 5.4, as described in the PHP manual's page about call_user_func_array() . The only workaround I can find for the difference in behavior between PHP 5.3, which is still supported on RHEL 6, and PHP 5.4 and later is to port the entire application to use a library that doesn't use call_user_func_array() in the first place, such as replacing all use of MySQLi with PDO. This can be a pain for a large application. For more information, see Breaking changes in PHP 5.3 and Breaking changes in PHP 5.4. Other languages have managed minor version changes better.

Parse errors and undefined function errors are fatal rather than throwing an exception that the caller can catch.

[This] doesn't make sense to me. How many languages throw an exception on a parse error?

I want to be able to do try { include_once("some_file.php"); } catch (SyntaxError $e) { ... } or try { some_function(); } catch (NameError $e) { ... } both of which Python supports. Likewise, Java's class loader throws an exception when it can't load a class.

Further, he seems to hate the fact that PHP doesn't have MORE fatal errors.

Then let him use the warning-to-ErrorException snippet in the manual to turn warnings into exceptions that can be caught or left unhandled as needed.

I'm convinced that he'd complain, as he did in other cases, if a parse error *wasn't* fatal.

If a parse error threw an exception, this would satisfy both him (who wants things to be fatal by default) and me (who wants things to be not-fatal by choice).

Re:Six identifiable bullet points

[Lab Rat Jason]

I've used PHP for 12+ years. I have always hated how often I have to refer to reference materials because I can't remember the way a function is spelled, order of parameters, etc. I've never been able to put my finger on it exactly, but PHP has always just bothered me with it's inconsistencies. Reading the fractal post has opened my eyes! I've experienced no less than half of the issues listed, some of which I never was able to resolve why (just ended up coding around the issue). Mostly I've gotten used to using frameworks like Zend and Propel to abstract away a lot of these issues, but that's not a fix, and it's likely to introduce additional security issues.

I've tinkered around with C# for a while now, and just this last year I've gotten serious about learning it for work. The lesson I learned from reading the fractal post is this: PHP has F*cked me up and made me a horrible coder, and has ruined me from learning C# properly. I have to unlearn all the bad habits I picked up in PHP before I can effectively code in any other language.

-J

Re:Six identifiable bullet points

[tepples]

If you choose a weakly typed language and are unable to remember how weak typing works, you shouldn't have chosen a weakly typed language in the first place, instead of writing long-ass rants about it.

But it's not like everyone has a meaningful choice. There was a time when a particular weakly-typed language had a near monopoly among entry-level web hosts. "Want Python? That'll cost you extra per month. Want Java? That'll cost you a lot extra per month."

Re:Six identifiable bullet points

[Calavar]

What? I'm not defending PHP. I just wrote a two page long post ripping apart a defense of PHP!

Re:Six identifiable bullet points

[Calavar]

As Patman64 already said, it seems that you are the one that is laughably ignorant. PHP and JavaScript are the exception to the rule. Try this in Python:

>>> "0" == "0000"
False

Try this in Ruby

irb(main):001:0> "12" + 2
TypeError: no implicit conversion of Fixnum into String
from (irb):1:in `+'
from (irb):1
from /bin/irb:12:in `'

Try this in Lua

> print(null == 0)
false

It's not as if PHP's hidden casting saves you any effort either. If I actually wanted to compare a string to an int in any of those other languages, it's absurdly simple:

Python:

print(int("150") == 150)

Ruby:

puts "150".to_i == 150

Lua:

print(tonumber("150") == 150)

Re:Six identifiable bullet points

[narcc]

Because reading is difficult for you:

The claim was that == was intransitive. My claim was that, like every other language, transitivity only breaks down when you start to mix types.

Feel silly yet? You should.

As Patman64 already said

And you felt the need to repeat it? Even though his reply was completely idiotic? Why?

Re:Six identifiable bullet points

[Calavar]

Okay, give one example in Python, Ruby, or Lua where the == operator is intransitive.

Re:Six identifiable bullet points

[narcc]

Here you go:

>>> 1 == 1.0
True
>>> 2 == 2.0
True
>>> 1 / 2 == 1.0 / 2.0
False

Something silly (that you'll, hopefully, understand) to show you what that claim looks like to everyone who's thought about it for at least 30 seconds.

>>> 1/2==1/3
True

A bit more obvious, but to the baffled and the unthinking it looks like Python can't be trusted with simple arithmetic. You've, sadly, fallen for the trap because you bought in to the meme and are thus willing to accept any argument that supports the position you've taken (not arrived at) even if it's silly nonsense.

Re:Six identifiable bullet points

[Calavar]

It seems that you don't understand what transitivity is. Transitivity means that A == B and B == C implies A == C. What you've shown is A == D and B == E does not imply A / D == B / E. Where the hell is the A == B statement? There is none. Instead you are essentially saying A / A is not always equal B / B, which has nothing to do with transitivity. (BTW, this is true even in pure mathematics if A == 0 or B == 0.) Nice try, though.

Re:Six identifiable bullet points

[Calavar]

And the second half of your post has nothing to do with transitivity either. In fact, Python is quite transitive in this case: >> 1/3 == 1/2
True
>> 1/3 == 1/4
True
>> 1/4 == 1/2
True >> 4/3 == 1/2
False
>> 4/3 == 1/4
False
>> 1/4 == 4/3
False

Re:Six identifiable bullet points

[narcc]

Actually, it seems that YOU don't know what transitivity is. I'm not surprised. The autodidacts have taken over slashdot.

What you've shown is A == D and B == E does not imply A / D == B / E. Where the hell is the A == B statement?

Okay, basic math for you:
If a=b and c=d then a/c = a/d (as c=d) = b/c = b/d (as b=a and d=c)

Nice try, though. I'm sure your local community college has a remedial math course for you.

Re:Six identifiable bullet points

[narcc]

And the second half of your post has nothing to do with transitivity either.

As I took great pains to point out. Good job, Captain Obvious.

Now, read it again. Do you see the point I was trying to make?

I'm sure that your local community college also has a remedial reading course.

Re:Six identifiable bullet points

[Calavar]

Look, you are trying to build an argument with a wall of cards, but it simply isn't going to work.

You just told me a/c == a/d and a/d == b/d implies a/c == b/d. That would be an example of transitivity, I grant you that. The problem is that in the example you have, a/c != a/d:

>>> A = 1
>>> C = 2
>>> B = 1.0
>>> D = 2.0
>>> A / C
0
>>> A / D
0.5
>>> A / C == A / D
False

So if a/c != a/d, why in the world would a/d == b/d implies a/c == b/d? Again, don't say "but a/c == a/d in mathematics" because that has nothing to do with transitivity. I never said that a problem with PHP is that division operations don't give you the same result that they would in pure mathematics. I said one problem is that PHP isn't transitive.

Re:Six identifiable bullet points

[Calavar]

No, you didn't take great pains to point anything out. If you did, you would have said, "and this next example has nothing to do with transitivity, but..." The first half of your post has nothing to do with transitivity either, which I just explained in my response to your other post.

Re:Six identifiable bullet points

[narcc]

You just told me a/c == a/d and a/d == b/d implies a/c == b/d. That would be an example of transitivity, I grant you that. The problem is that in the example you have, a/c != a/d:

Which is precisely what you asked for! If a=b and c=d then it follows that a/c=a/d=b/c=b/d In Python a/c !=b/d.

See, the complaint about intransitive operators is laughable nonsense. It's just like every other language in that == is transitive until you start mixing types.

I mean, you've just conceded my entire argument. What is the objection?

Re:Six identifiable bullet points

[narcc]

Have you checked to see if your local community college offers a remedial reading course?

Something silly (that you'll, hopefully, understand) to show you what that claim looks like to everyone who's thought about it for at least 30 seconds.

There you go.

The first half of your post has nothing to do with transitivity either, which I just explained in my response to your other post.

Which you admit you were completely wrong about in your other reply. It's time to let it go, man. The facts are not on your side.

Re:Six identifiable bullet points

[Calavar]

Look, I don't understand how many times I have to explain this. In Python 1 / 2 is not equal to 1.0 / 2.0, and you are pretending that this has something to do with transitivity. It. Does. Not.

If a=b and c=d then it follows that a/c=a/d

No, it doesn't. Just because it is true when dealing with real numbers in traditional mathematics, doesn't mean it is true in other scenarios. The phenomenon where a=b and c=d implies a/c = a/d, is called substitution, not transitivity, as any damn middle school level text can explain to you: http://hotmath.com/hotmath_hel.... The Python division operation is different from the standard mathematical division operation in that it is not satisfy the substitution property of equality. This has nothing to do with transitivity. Admit it. At this point you are either too boneheaded to understand the difference between division and equality or too stubborn to admit that your are wrong. Whatever the case may be, I'm not going to needlessly expend the energy to argue with you anymore.

Re:Six identifiable bullet points

[narcc]

No, it doesn't.

Yes, it does. That just basic math. a/c=a/d=b/c=b/d pretty obviously shows a transitive relation! How can you possibly deny this? (Try this, given A=B=C=D, then, by necessity, A=C, A=D, B=A, and B=C. As A=B and B=C so must A=C or A=C and C=D so must A=D, etc. Really simple stuff here. Well, unless you're an autodidact -- those guys have a lot of trouble with stuff like this.)

If you actually want to continue making "your" ridiculous claim, in face of evidence that makes it look foolish, you'll need to show me a case where PHP's == operator is intransitive without mixing types.

Betcha can't do that!

Re:Six identifiable bullet points

[narcc]

Whatever the case may be, I'm not going to needlessly expend the energy to argue with you anymore.

I missed this bit earlier. Fine. If you hate my example, try this one from Lua:

a=10
b="011"
c="02"
print(a,b,c)
print(a

I'm hoping that there's a limit to your denial.

I'd like to leave my challenge open: Show me a case where PHP's == operator is intransitive without mixing types. Betcha can't.

Re:Six identifiable bullet points

[tepples]

the ability to convert any error, warning or notice to a catchable exeption?

Good luck catching the error from including a module with a syntax error or from calling a function that doesn't exist. Python makes these catchable (ImportError and NameError respectively); PHP makes them fatal even if that's not what the programmer wants.

Re:Six identifiable bullet points

[tepples]

That's not what I get:

Python 2.7.5 (default, May 15 2013, 22:43:36) [MSC v.1500 32 bit (Intel)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> from __future__ import division
>>> 1 == 1.0
True
>>> 2 == 2.0
True
>>> 1 / 2 == 1.0 / 2.0
True
>>> 1/2==1/3
False
>>>

True, I "cheated" by including a statement that turns on the "divide correctly" flag, which is off by default in Python 2.7 for compatibility with pre-Python 2.2 code. But it's on by default in Python 3, and there are far fewer such breaking changes to language semantics in Python than in PHP. And in Python, you turn on a language feature in the module, not in an INI file to which a hosting subscriber might not have access.

Re:Six identifiable bullet points

[narcc]

Python: A fractal of bad design

#347: There's an option, off by default, to divide correctly.

Re:Six identifiable bullet points

[tepples]

there are far fewer such breaking changes to language semantics in Python than in PHP

Python: A fractal of bad design

The list of breaking changes within Python 2.x series is far shorter than the list of breaking changes within PHP 5.x or the list of breaking changes controlled by php.ini between installations of the latest PHP (that is, 5.x). I doubt that there are even 350 such issues, as you insinuated.

Re:Six identifiable bullet points

[narcc]

The list of breaking changes within Python 2.x series is far shorter than the list of breaking changes within PHP 5.x

Prove it.

Re:Six identifiable bullet points

[tepples]

The keyword to enable these changes in Python is from __future__ import . Seven features were introduced during Python 2.x: nested_scopes, generators (which added the keyword yield), division, absolute_import, with_statement (which added the keyword with), print_function (which removed the keyword print), and unicode_literals. Some already default on since 2.6 (nested_scopes, generators, and with_statement). In each case, there's a transition period when a module can choose one behavior or the other, and a module expecting one behavior can call a module expecting another behavior. The only breaking change that doesn't allow this sort of mixing is 2.x to 3.x. No breaking changes that I'm aware of have been introduced in Python 3.x since Python 3.0.

I went through the PHP migration guides and listed incompatible changes to the language itself: 5.1 to 5.2 (change to behavior of $value % 0, change to object-to-string conversion semantics), 5.2 to 5.3 (fatal error when passing a value to a function expecting a reference instead of creating a temporary anonymous variable, change to handling of $this in call_user_func_array(), and some new reserved keywords), and 5.3 to 5.4 (removal of call-time pass-by-reference, removal of computed break and continue statements, and some new reserved keywords). And at all times, all programs must use the syntax and semantics of the installed version of PHP.

Re:Six identifiable bullet points

[narcc]

You could just admit that you couldn't prove your assertion.

The list of breaking changes within Python 2.x series is far shorter than the list of breaking changes within PHP 5.x

Go ahead, I'll wait.

I'm sure you have actual data to back-up your claim. Surely, you didn't just make that assertion hoping I'd blindly believe it, particularly with Python's rather notorious track-record with respect to compatibility between minor versions in the 2.x branch.

No, you're not that bold! You MUST have some data.

Right?

Re:Six identifiable bullet points

[tepples]

You could just admit that you couldn't prove your assertion.

I admit that it would take more research effort to provide a rigorous proof of the tendency of Python 2.5+ to have fewer breaking changes than PHP 5.2+ than I am willing to expend to make a point in a Slashdot comment Slashdot.

Re:Six identifiable bullet points

[narcc]

In short: You pulled it out of your ass.

I can accept that.

Re:Engineer?

[OzPeter]

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:Formal specifications are pretty useless for th

[Daniel Hoffmann]

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

[Anonymous Coward]

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:How did we get along for so many years without

[ruir]

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

Re:Formal specifications are pretty useless for th

[rockmuelle]

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

Full specification text:

[goodmanj]

PHP Formal Specification:

1) Don't use PHP.

Re:Full specification text:

[lgw]

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.

Re:Full specification text:

[cowdung]

Look at any better languages like Python or Ruby lately?

Python is not only simpler than PHP.. its actually designed.

PHP is the garbage of programming languages.. today's BASIC.
If Dijkstra were alive today he'd say that PHP causes brain damage.

Factors that force choice of language

[tepples]

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.

Why binary?

[tepples]

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:Formal specifications are pretty useless for th

[CrashNBrn]

Also, Hack:a new (Open Source) programming language for HHVM

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/ 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,

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:Engineer?

[Megane]

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:Existing app

[Zero__Kelvin]

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

Re:Existing app

[goodmanj]

Bitter tears of regret.

Re:Formal specifications are pretty useless for th

[Chris Mattern]

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

[Anonymous Coward]

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

[Mister Liberty]

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.

its why devs cringe.

[Anonymous Coward]

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.

Re:Formal specifications are pretty useless for th

[lgw]

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:Engineer?

[lgw]

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:Formal specifications are pretty useless for th

[squiggleslash]

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

[gweihir]

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

[gweihir]

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

[gweihir]

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

[gweihir]

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

[gweihir]

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

[gweihir]

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

[narcc]

This is Slashdot so ... probably not.

Re:Engineer?

[narcc]

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:Formal specifications are pretty useless for th

[Urkki]

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

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

Re:Formal specifications are pretty useless for th

[angel'o'sphere]

Lucky me, that I only used (except for PHP) languages that have a formal specification.

If you know so many languages that have none (we are talking about programming languages, not computer languages, right?) do you like to point some out?

Re:Formal specifications are pretty useless for th

[angel'o'sphere]

I beg to differ.

First of all C's syntax was defined or described in a graphical way. That is as formal as any 'formal specification language' secondly: the word formal is not the point, the point we are talking about is 'specification' ...
Or how do you define a 'formal specification language' used to write a 'formal specification' for another language? Do you really have a 'formal meta specification language' to be able to define the 'formal specification language' to be able to define 'the language'? Or do you use 'informal' but 'rather precise' natural language at some point?

For me C and C++ and Pascal etc. was always 'formally enough' described. Sorry, a precise definition does not need to be on a 'formal' language.

Here it is..

[cowdung]

I formally specify PHP to be crap!

Hygiene technician

[ameen.ross]

http://youtu.be/VBxm7EP93h4?t=...

Re:Formal specifications are pretty useless for th

[brantondaveperson]

Doubtless true - but imagine how much better the world of practical day-to-day computing would be if we *could* prove compilers to be correct. I don't disagree that formal methods are more or less useless for real-world problems today, but does that mean that we shouldn't continue to investigate them? I hated my formal methods class when studying Computer Science at uni as much as the next guy (well, I guess some people probably enjoyed it), but unless there's some reason that such methods can never be applied to compiler-correctness-proof (halting problem kinda thing), then surely it's worth continuing to look into it?

Re:Formal specifications are pretty useless for th

[johnsnails]

Same goes for where you can fish in Australian waters... http://www.dpi.nsw.gov.au/fish...

Re:Formal specifications are pretty useless for th

[Daniel Hoffmann]

Well there is "formal" as in the "rigorous" and "official" sense and then there is "formal" in the Formal Languages sense. The article does not mention which one is being built, I assumed it was the first, not the latter. Honestly even PHP people have more to do than proving theorems about PHP.

Re:Formal specifications are pretty useless for th

[lgw]

A formal specification is a specification done in a formal specification language. There is no other meaning of that term.

What, there are language specs that don't have an EBNF or similar for valid statements in the language? Seems odd.

theory, you could check a formal specification for soundness using an automated theorem prover

Ooh, sounds magical. Let me know when you find a theorem prover that is (even "in theory") complete and consistent (and runs in finite time).

Re:Formal specifications are pretty useless for th

[Gallomimia]

But will they do what Microsoft has been trying to do web standards for two decades?

Re:Engineer?

[Gallomimia]

At least you're not a sanitary engineer.

Re:Formal specifications are pretty useless for th

[gweihir]

It is "as formal as in a formal specification language" exactly if it is done in a formal specification language. There really is no other way. And yes, "formal" is very much the central and most important point if somebody claims to have a formal specification. The "formal" is not a modifier to "specification", a "formal specification" is one very specific thing. I think you have no clue what "formal" actually means. Your second paragraph demonstrates that. Maybe stop commenting on things you do not understand?

And anyways, have you read what I wrote above? At the very least you have not understood it. Let me re-iterate: "Formal" and "exact" are orthogonal concepts. Of course, you have to understand both to see that.

Re:Formal specifications are pretty useless for th

[gweihir]

I am not confused at all. I never wrote "formal language", I wrote "formal specification language", which is a completely different beast. You fail.

Re:Formal specifications are pretty useless for th

[gweihir]

A formal specification is a specification done in a formal specification language. There is no other meaning of that term.

What, there are language specs that don't have an EBNF or similar for valid statements in the language? Seems odd.

If you had the least clue what you are talking about (or actually had read what I wrote), you would know that there are informal specifications around and that this is in fact the normal way to do them. You would also know that putting in some formal grammar does not make a specification a formal one.

theory, you could check a formal specification for soundness using an automated theorem prover

Ooh, sounds magical. Let me know when you find a theorem prover that is (even "in theory") complete and consistent (and runs in finite time).

You throw around big words but do not understand them. Pathetic.

Re: Formal specifications are pretty useless for t

[gweihir]

Is somebody promises a "formal specification" they promise something very, very specific. In practice, you usually only need a "specification" and in fact, as I wrote before, a formal specification is typically pretty useless. People just should not try to inflate the perceived quality of their product by using words they do not understand.

Re:Formal specifications are pretty useless for th

[gweihir]

And "fail to read plain English". The C standard is not a formal specification at all. It is a formal standard though. A formal standard is made formal by a formal standardization process. A formal specification is made formal by exclusive use of a formal specification language. Hint: "formal" means two different things here.

Sessh, does nobody know any basic CS terminology anymore?

Re:Formal specifications are pretty useless for th

[gweihir]

You very likely have used not a single language that has a formal specification. That is because there is not a single mainstream language that has one. The only language with a formal specification I know is Algol68.

Re:Formal specifications are pretty useless for th

[gweihir]

They are not. But it takes some _actual_ understanding to see that.

Re:Formal specifications are pretty useless for th

[gweihir]

They are not. In fact, not at all. Most of mathematics is done informal, yet exact. Of course some intelligence is required on the side of the user and the writer.

Re:Formal specifications are pretty useless for th

[gweihir]

Well, it certainly is a good thing that they try to put this language on a solid basis. It is used in far too many places to remain without a specification.

Re:Formal specifications are pretty useless for th

[next_ghost]

I am not confused at all. I never wrote "formal language", I wrote "formal specification language", which is a completely different beast. You fail.

"Formal specification language" is "formal" because it's a formal language in the same sense that any of the many dialects of "regular expressions" or even PHP itself is a formal language. Nothing more, nothing less. The fact that you keep calling C/C++ standard specifications "informal" means that you're just parrotting buzzwords without actually understanding them. When you talk about formal specification languages or any formal languages at all, the word "informal" is inapplicable because it's a completely different kind of formality (syntactic formality) than the word "informal" implies (semantic formality). The word "informal" has meaning only when you want to make a distinction between formalised natural language and non-formalised natural language.

Re:Formal specifications are pretty useless for th

[lgw]

Understanding implies the ability to explain ones position, not merely assert it. You come off like those clowns who go on about proofs of program correctness, but perhaps that's a mistaken impression

Can you give an example of a formal language spec? Are you talking about an actual set of formal transforms to object code or somesuch?

BTW, set-ups like a C compiler written in C are very much in line with Godel statements. There certainly exists source code for which the question "does this compiler compile this source code correctly" cannot have a useful answer as a formal proof (and the examples easiest to contrive would include the compiler itself in said source code).

Re:Formal specifications are pretty useless for th

[lgw]

Well, if you steadfastly refuse to explain your use of your pet phrase "formal specification language", you'll continue to fail to communicate. Whatever point you're trying to make, no one here outside your head is getting it.

Automatic ahead of time compilation

[tepples]

Then perhaps JIT might not be the best term. Ahead of time compilation managed by the PHP engine could help; it's the same philosophy that APC uses and Python uses when importing a module. I was mostly objecting to the concept of distributing a compiled PHP script for two reasons. First, debugging integration with a library is more difficult if you don't have the library's source in front of you, and second, ABI is even more likely to break between platforms or minor versions than PHP already is.

Web application as Apache module

[tepples]

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.

It won't if it's run through CGI or FastCGI. But it will if it's loaded as a module into your web server.

True division in Python 3

[tepples]

Let's try that again:

Python 3.2.3 (default, Feb 27 2014, 21:33:50)
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 1 == 1.0
True
>>> 2 == 2.0
True
>>> 1 / 2 == 1.0 / 2.0
True
>>> 1/2==1/3
False
>>>
pino@pino-laptop:~$ php -a
Interactive shell

php > echo 1 == 1.0;
1
php > echo 2 == 2.0;
1
php > echo 1/2 == 1.0/2.0;
1
php > echo 1/2 == 1/3;
php >

PHP and recent Python give the same results here. Yes, I'll admit that PHP arrived at what Python calls "true division" behavior years before Python did, and legacy Python (3.x has been current for years now) does not use true division by default.