PHP Finally Getting a Formal Specification

Formal specifications are pretty useless for this by gweihir · 2014-07-31 06:20 · Score: 0

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.

--
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.

Re:Formal specifications are pretty useless for th by Anonymous Coward · 2014-07-31 06:23 · Score: 1

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

Re:Formal specifications are pretty useless for th by gweihir · 2014-07-31 06:24 · Score: 2

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

--
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.

Re:Formal specifications are pretty useless for th by Anonymous Coward · 2014-07-31 06:26 · Score: 2, Insightful

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 by gweihir · 2014-07-31 06:27 · Score: 2

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

--
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.

its why devs cringe. by nimbius · 2014-07-31 06:29 · Score: 3, Insightful

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.

--
Good people go to bed earlier.

Re:its why devs cringe. by Anonymous Coward · 2014-07-31 06:57 · Score: 0

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. by OzPeter · 2014-07-31 06:57 · Score: 4, Insightful

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.

--
I am Slashdot. Are you Slashdot as well?
Re:its why devs cringe. by Bacon+Bits · 2014-07-31 07:16 · Score: 1

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.

--
The road to tyranny has always been paved with claims of necessity.
Re:its why devs cringe. by Anonymous Coward · 2014-07-31 07:30 · Score: 0

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. by Anonymous Coward · 2014-07-31 07:32 · Score: 0

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. by Anonymous Coward · 2014-07-31 07:37 · Score: 1

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. by Anonymous Coward · 2014-07-31 07:44 · Score: 0

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. by Anonymous Coward · 2014-07-31 10:13 · Score: 0

Personally I just stayed away from it because it was hilariously bad.
1 month was enough for me to never touch it again.
Re:its why devs cringe. by rdnetto · 2014-07-31 10:34 · Score: 1

Putting aside the whole whitespace debate(*), I'm pretty sure that python has its own list of issues.
My understanding is that Python's two biggest issues are a lack of static typing (justifiable, but annoying) and the ability to use arbitrary objects as dictionaries. The latter causes significant issues when trying to optimize code, because something as simple as reading a value from a property becomes a hashtable lookup.

--
Most human behaviour can be explained in terms of identity.
Re:its why devs cringe. by ShadowRangerRIT · 2014-07-31 11:19 · Score: 2

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.

--
$_ = "wftedskaebjgdpjgidbsmnjgcdwatb"; tr/a-z/oh, turtleneck Phrase Jar!/; print
Re:its why devs cringe. by Anonymous Coward · 2014-07-31 11:23 · Score: 0

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. by Vanders · 2014-07-31 11:30 · Score: 1

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.

--
Syllable : It's an Operating System
Re:its why devs cringe. by squiggleslash · 2014-07-31 13:39 · Score: 1

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

--
You are not alone. This is not normal. None of this is normal.
Re:its why devs cringe. by narcc · 2014-07-31 14:53 · Score: 1

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.

--
Required reading for internet skeptics
Re:its why devs cringe. by narcc · 2014-07-31 15:05 · Score: 1

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

--
Required reading for internet skeptics
Re:its why devs cringe. by Anonymous Coward · 2014-07-31 17:21 · Score: 0

Do you not put whitespace in your code? That is just madness.
Re:its why devs cringe. by tlhIngan · 2014-07-31 17:22 · Score: 1

* 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. by the_arrow · 2014-07-31 17:37 · Score: 1

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

--
/ The Arrow
"How lovely you are. So lovely in my straightjacket..." - Nny
Re:its why devs cringe. by angel'o'sphere · 2014-07-31 18:32 · Score: 1

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

--
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Re:its why devs cringe. by angel'o'sphere · 2014-07-31 18:37 · Score: 1

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

--
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Re:its why devs cringe. by macson_g · 2014-07-31 19:44 · Score: 1

Want static typing? Use Cython.
Re:its why devs cringe. by brantondaveperson · 2014-07-31 21:36 · Score: 1

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. by squiggleslash · 2014-07-31 23:43 · Score: 1

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.

--
You are not alone. This is not normal. None of this is normal.
Re:its why devs cringe. by Anonymous Coward · 2014-08-01 04:48 · Score: 0

You are probably using a personal definition of "visually identical" which ignores whitespace. Since whitespace is significant in Python and spacing is quite visible to anyone else than you, it seems you are trying really hard to find something to complain about.
Next you're gonna tell me how 1 and 0 are visually similar to I, l and O yet they are seen as completely different entities by the language.
Re:its why devs cringe. by jambox · 2014-08-01 10:35 · Score: 1

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.

--
You thought you could break the laws of physics without paying the PRICE?
Re:its why devs cringe. by narcc · 2014-08-01 15:52 · Score: 1

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.

--
Required reading for internet skeptics
Re:its why devs cringe. by dotancohen · 2014-08-02 01:56 · Score: 1

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.

--
It is dangerous to be right when the government is wrong.
Re:its why devs cringe. by hobarrera · 2014-08-03 09:44 · Score: 1

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 by Bacon+Bits · 2014-07-31 06:31 · Score: 1

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.

--
The road to tyranny has always been paved with claims of necessity.

MUTEX by Anonymous Coward · 2014-07-31 06:33 · Score: 0

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

(PHP XOR Formal) AND (PHP XOR Specification)

Re:Formal specifications are pretty useless for th by Anonymous Coward · 2014-07-31 06:34 · Score: 0

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?

PHP is going away? by Anonymous Coward · 2014-07-31 06:39 · Score: 0

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

At last by geminidomino · 2014-07-31 06:40 · Score: 2

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 by NoNonAlphaCharsHere · 2014-07-31 06:42 · Score: 5, Funny

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

Re:PHP Finally Getting a Formal Specification by sootman · 2014-07-31 06:58 · Score: 1

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

--
Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
Re:PHP Finally Getting a Formal Specification by NoNonAlphaCharsHere · 2014-07-31 07:12 · Score: 4, Funny

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 by Megane · 2014-07-31 08:15 · Score: 4, Funny

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

--
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
Re:PHP Finally Getting a Formal Specification by Anonymous Coward · 2014-07-31 09:17 · Score: 0

I smiled.
Re:PHP Finally Getting a Formal Specification by Anonymous Coward · 2014-07-31 09:24 · Score: 0

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()
Re:PHP Finally Getting a Formal Specification by w_dragon · 2014-07-31 09:48 · Score: 1

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 by NoNonAlphaCharsHere · 2014-07-31 15:21 · Score: 1

Well played. I think yours is the funniest in the thread. And tooooo true.
Re:PHP Finally Getting a Formal Specification by larpon · 2014-07-31 18:19 · Score: 1

Get it via file_get_contents()!

Re:Formal specifications are pretty useless for th by Tailhook · 2014-07-31 06:46 · Score: 5, Informative

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.

--
Maw! Fire up the karma burner!

Engineer? by Anonymous Coward · 2014-07-31 06:47 · Score: 0

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? by OzPeter · 2014-07-31 07:03 · Score: 4, Informative

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.

--
I am Slashdot. Are you Slashdot as well?
Re:Engineer? by Anonymous Coward · 2014-07-31 07:08 · Score: 0

... or PHP engineer != Facebook engineer and PHP core contributor
Re:Engineer? by Anonymous Coward · 2014-07-31 07:38 · Score: 0

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.
Re:Engineer? by Megane · 2014-07-31 08:43 · Score: 1

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.

--
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
Re:Engineer? by Anonymous Coward · 2014-07-31 11:04 · Score: 0

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? by lgw · 2014-07-31 12:19 · Score: 1

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!

--
Socialism: a lie told by totalitarians and believed by fools.
Re:Engineer? by narcc · 2014-07-31 15:17 · Score: 1

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.

--
Required reading for internet skeptics
Re:Engineer? by Anonymous Coward · 2014-07-31 15:33 · Score: 0

I look forward to the day when I can have my sandwiches made by Subway's sandwich engineers.
Re:Engineer? by Anonymous Coward · 2014-07-31 19:29 · Score: 0

> a serious disservices to REAL engineers
Namely, denting their fragile egos.
Re:Engineer? by Anonymous Coward · 2014-07-31 20:01 · Score: 0

Used to be that everybody and his dog had "manager" in his job title. Now it's "engineer". Wonder what's next.
In the meantime I'll be "general management engineer" for a while. Thank you, thank you, I'll be here all week.
Re:Engineer? by Anonymous Coward · 2014-07-31 20:08 · Score: 0

I got spammed for years by recruiters (who had not even deigned answer my initial message to them, just straight dumped my email address in their spam database) who offered me "business intelligence" jobs on the basis of the keywords they had so carefully filed me under--without my consent or input whatsoever. There was no "BUSINESS INTELLIGENCE" among them, but one of the keywords was "DEBIAN". Verily, expert IT recruiters utilizing the very latest in teknologee.
It stopped when they finally figured out who was sending all those anonymised spam reports. Because that obviously is a better idea than stopping with their wholesale violation of applicable (European) spam laws.
Re:Engineer? by Anonymous Coward · 2014-07-31 21:16 · Score: 0

As a sanitation engineer, I feel your pain.
Re:Engineer? by Anonymous Coward · 2014-08-01 00:25 · Score: 0

In most European countrees engineer is an academic degree and you can't call yourself one unless you have a proper engineer diploma from a university. In some countries it's an exact equivalent to a master's degree in non-technical fields (i.e. you can pursue a doctorate after completing it), while in others it's either a bit higher (it can be studied after the completion of a master's degree) or a bit lower (the other way around). In either case, no matter what your job is and how many licenses you have, state or not, if you don't have a higher education engineer diploma, you're not an engineer.
Re:Engineer? by Gallomimia · 2014-08-01 05:20 · Score: 1

At least you're not a sanitary engineer.

--
Sadly, a Libertarian cannot force his views on another, and freedom cannot spread as does the cancer known as religion.

I'm waiting... by Anonymous Coward · 2014-07-31 06:49 · Score: 0

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

Re:Formal specifications are pretty useless for th by Dogtanian · 2014-07-31 06:50 · Score: 1

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.

--
"Slashdot - News and Chat Sites Deviant". (Click "homepage" link above for details).

A proof that nobody gives a shit about formal spec by osiaq · 2014-07-31 06:50 · Score: 1

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? by Anonymous Coward · 2014-07-31 06:55 · Score: 0

Will this change anything?

A clean break is needed, like "Visual Fred" by tepples · 2014-07-31 06:55 · Score: 1

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" by Dogtanian · 2014-07-31 07:27 · Score: 1

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

--
"Slashdot - News and Chat Sites Deviant". (Click "homepage" link above for details).
Re:A clean break is needed, like "Visual Fred" by Anonymous Coward · 2014-07-31 07:45 · Score: 0

(*) 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" by Anonymous Coward · 2014-07-31 11:11 · Score: 0

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" by tepples · 2014-07-31 14:26 · Score: 1

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" by exploder · 2014-07-31 14:27 · Score: 1

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.

--
Yo dawg, I heard you like the Ackermann function, so OH GOD OH GOD OH GOD

Re:How did we get along for so many years without by ChipMonk · 2014-07-31 07:00 · Score: 1

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

Six identifiable bullet points by tepples · 2014-07-31 07:00 · Score: 2

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

Re:Six identifiable bullet points by Anonymous Coward · 2014-07-31 08:37 · Score: 0

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 by tepples · 2014-07-31 08:49 · Score: 1

So what, may I ask, are your superior points?
Re:Six identifiable bullet points by Calavar · 2014-07-31 10:13 · Score: 1

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 by narcc · 2014-07-31 15:32 · Score: 1

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.

--
Required reading for internet skeptics
Re:Six identifiable bullet points by narcc · 2014-07-31 15:38 · Score: 1

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

--
Required reading for internet skeptics
Re:Six identifiable bullet points by Patman64 · 2014-07-31 19:12 · Score: 1

, 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 by Anonymous Coward · 2014-07-31 21:52 · Score: 0

I am a diehard C++ fan,
I like you. But you're defending PHP? This unsettles me.
Re:Six identifiable bullet points by Anonymous Coward · 2014-08-01 01:15 · Score: 0

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.
You mean like, I don't know, try-catch-finally and the ability to convert any error, warning or notice to a catchable exeption? Yep, being ignorant of it must suck.

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.
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.
I'm the first guy to admit PHP has a fuckton of problems, quirks and terrible design decisions but I'm yet to see a rant about it that isn't at least 90% FUD.
Re:Six identifiable bullet points by tepples · 2014-08-01 01:45 · Score: 1

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 by Lab+Rat+Jason · 2014-08-01 03:44 · Score: 1

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

--
Which has more power: the hammer, or the anvil?
Re:Six identifiable bullet points by tepples · 2014-08-01 04:43 · Score: 1

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 by Calavar · 2014-08-01 05:27 · Score: 1

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 by Calavar · 2014-08-01 05:58 · Score: 1

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 by narcc · 2014-08-01 15:37 · Score: 1

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?

--
Required reading for internet skeptics
Re:Six identifiable bullet points by Calavar · 2014-08-01 16:23 · Score: 1

Okay, give one example in Python, Ruby, or Lua where the == operator is intransitive.
Re:Six identifiable bullet points by narcc · 2014-08-01 17:15 · Score: 1

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.

--
Required reading for internet skeptics
Re:Six identifiable bullet points by Calavar · 2014-08-02 06:12 · Score: 1

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 by Calavar · 2014-08-02 06:20 · Score: 1

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 by narcc · 2014-08-02 06:50 · Score: 1

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.

--
Required reading for internet skeptics
Re:Six identifiable bullet points by narcc · 2014-08-02 06:53 · Score: 1

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.

--
Required reading for internet skeptics
Re:Six identifiable bullet points by Calavar · 2014-08-02 08:05 · Score: 1

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 by Calavar · 2014-08-02 08:10 · Score: 1

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 by narcc · 2014-08-02 10:52 · Score: 1

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?

--
Required reading for internet skeptics
Re:Six identifiable bullet points by narcc · 2014-08-02 10:55 · Score: 1

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.

--
Required reading for internet skeptics
Re:Six identifiable bullet points by Calavar · 2014-08-02 12:34 · Score: 1

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 by narcc · 2014-08-02 13:21 · Score: 1

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!

--
Required reading for internet skeptics
Re:Six identifiable bullet points by narcc · 2014-08-02 18:50 · Score: 1

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.

--
Required reading for internet skeptics
Re:Six identifiable bullet points by tepples · 2014-08-07 05:06 · Score: 1

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 by tepples · 2014-08-07 05:14 · Score: 1

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 by narcc · 2014-08-07 05:33 · Score: 1

Python: A fractal of bad design
#347: There's an option, off by default, to divide correctly.

--
Required reading for internet skeptics
Re:Six identifiable bullet points by tepples · 2014-08-07 05:38 · Score: 1

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 by narcc · 2014-08-07 08:46 · Score: 1

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.

--
Required reading for internet skeptics
Re:Six identifiable bullet points by tepples · 2014-08-07 09:26 · Score: 1

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 by narcc · 2014-08-07 11:01 · Score: 1

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?

--
Required reading for internet skeptics
Re:Six identifiable bullet points by tepples · 2014-08-07 12:08 · Score: 1

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 by narcc · 2014-08-07 13:28 · Score: 1

In short: You pulled it out of your ass.
I can accept that.

--
Required reading for internet skeptics

Re:Formal specifications are pretty useless for th by Daniel+Hoffmann · 2014-07-31 07:07 · Score: 4, Informative

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 by Anonymous Coward · 2014-07-31 07:17 · Score: 1

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 by ruir · 2014-07-31 07:20 · Score: 2

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

thus someone useless got a name by Anonymous Coward · 2014-07-31 07:29 · Score: 0

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

Re:Formal specifications are pretty useless for th by rockmuelle · 2014-07-31 07:52 · Score: 2

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: by goodmanj · 2014-07-31 07:56 · Score: 2, Insightful

PHP Formal Specification:

1) Don't use PHP.

Re:Full specification text: by lgw · 2014-07-31 12:25 · Score: 4, Funny

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.

--
Socialism: a lie told by totalitarians and believed by fools.
Re:Full specification text: by cowdung · 2014-07-31 19:16 · Score: 1

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 by tepples · 2014-07-31 08:10 · Score: 1

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.

Existing app by tepples · 2014-07-31 08:14 · Score: 0

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

Re:Existing app by Zero__Kelvin · 2014-07-31 08:48 · Score: 2, Funny

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

--
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Re:Existing app by goodmanj · 2014-07-31 09:57 · Score: 1

Bitter tears of regret.
Re:Existing app by Anonymous Coward · 2014-07-31 11:49 · Score: 0

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

Why binary? by tepples · 2014-07-31 08:17 · Score: 1

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? by Anonymous Coward · 2014-07-31 09:37 · Score: 0

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? by Anonymous Coward · 2014-07-31 09:58 · Score: 0

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.

Re:Formal specifications are pretty useless for th by CrashNBrn · 2014-07-31 08:41 · Score: 3

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: Formal specifications are pretty useless for t by Anonymous Coward · 2014-07-31 09:05 · Score: 0

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

Re:Formal specifications are pretty useless for th by Chris+Mattern · 2014-07-31 10:18 · Score: 1

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 by Anonymous Coward · 2014-07-31 11:37 · Score: 1

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 by Mister+Liberty · 2014-07-31 11:39 · Score: 1

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. by Anonymous Coward · 2014-07-31 11:40 · Score: 1

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.

Full specification text: by Anonymous Coward · 2014-07-31 12:00 · Score: 0

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:Formal specifications are pretty useless for th by lgw · 2014-07-31 12:10 · Score: 1

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

--
Socialism: a lie told by totalitarians and believed by fools.

Re:Formal specifications are pretty useless for th by squiggleslash · 2014-07-31 13:44 · Score: 1

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.

--
You are not alone. This is not normal. None of this is normal.

Re:Formal specifications are pretty useless for th by gweihir · 2014-07-31 13:50 · Score: 1

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.

--
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.

Re:Formal specifications are pretty useless for th by gweihir · 2014-07-31 13:56 · Score: 4, Informative

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.

--
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.

Re:Formal specifications are pretty useless for th by gweihir · 2014-07-31 13:58 · Score: 1

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.

--
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.

Re:Formal specifications are pretty useless for th by gweihir · 2014-07-31 13:59 · Score: 1

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

--
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.

Re:Formal specifications are pretty useless for th by gweihir · 2014-07-31 14:02 · Score: 1

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?

--
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.

Re:Formal specifications are pretty useless for th by gweihir · 2014-07-31 14:05 · Score: 1

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

--
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.

Re:Formal specifications are pretty useless for th by narcc · 2014-07-31 14:45 · Score: 1

This is Slashdot so ... probably not.

--
Required reading for internet skeptics

Re:Formal specifications are pretty useless for th by Urkki · 2014-07-31 16:38 · Score: 1

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 by angel'o'sphere · 2014-07-31 18:41 · Score: 1

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?

--
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.

Re:Formal specifications are pretty useless for th by angel'o'sphere · 2014-07-31 18:47 · Score: 1

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.

--
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.

Here it is.. by cowdung · 2014-07-31 19:13 · Score: 1

I formally specify PHP to be crap!

Re:Here it is.. by Anonymous Coward · 2014-08-01 08:56 · Score: 0

Amen. With PHP it's probably not possible to FORMALLY define it EVER. PHP=PoopHighlyPiled never compiled

Re:Formal specifications are pretty useless for th by Anonymous Coward · 2014-07-31 20:07 · Score: 0

It's the difference between pseudo-code and having an actual running implementation. This is not only the grandparent's definition, it's the generally accepted definition of the term. Just because you're unfamiliar with the technology that does not mean you're correct to create a definition that best suits your limited expertise. Come off it.

The advantage of having a formal specification is that you can mechanically reason about the semantics of a language. This is not possible with an informal specification. Arguably, the PHP interpreter is a de facto specification, but it's difficult to translate theorems about source code and compiled binaries to theorems about the semantics of the language being model. This becomes incredibly important when trying to reason about (e.g., design) complicated optimizations. In fact, formal specifications (a very different beast from a "standard") have even been used to verify C compilers; as a practioner, surely you've been bitten by a compiler bug in the past and understand why this is important beyond mere theory and that "formal enough" is absolute nonsense.

Cf. http://en.wikipedia.org/wiki/Specification_language
Cf. http://en.wikipedia.org/wiki/CompCert

Hygiene technician by ameen.ross · 2014-07-31 20:27 · Score: 1

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

--
$(echo cm0gLXJmIC8= | base64 --decode)

Re:Formal specifications are pretty useless for th by brantondaveperson · 2014-07-31 21:25 · Score: 1

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 by johnsnails · 2014-07-31 23:39 · Score: 1

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 by Anonymous Coward · 2014-08-01 01:01 · Score: 0

It's the difference between pseudo-code and having an actual running implementation. This is not only the grandparent's definition, it's the generally accepted definition of the term. Just because you're unfamiliar with the technology that does not mean you're correct to create a definition that best suits your limited expertise. Come off it.

Sorry but both you and gweihir are a bit confused by the word "formal". There are two different meanings of "formal language":
1) in computer science linguistics: a set of symbols and grammar rules which define a (often infinite) set of accepted strings for an artificial language. Those symbols and rules may also have semantic meaning. Specification languages fall into this category. There's no deeper meaning behind them being called "formal" other than the fact that they were created artificially for a specific purpose.
2) in general: subset of natural language (e.g. English) which follows certain rules to make the meaning absolutely clear to at least a specific group of humans. Scientific papers are written in formal language. Court verdicts are written in formal language. Business contracts are written in formal language. Your doctor writes your medical history in formal language. This is the meaning that applies to "formal specification" of programming languages.

Re:Formal specifications are pretty useless for th by Daniel+Hoffmann · 2014-08-01 01:17 · Score: 1

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 by lgw · 2014-08-01 02:47 · Score: 1

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

--
Socialism: a lie told by totalitarians and believed by fools.

Re:Formal specifications are pretty useless for th by Gallomimia · 2014-08-01 05:19 · Score: 1

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

--
Sadly, a Libertarian cannot force his views on another, and freedom cannot spread as does the cancer known as religion.

Re:Formal specifications are pretty useless for th by gweihir · 2014-08-01 08:48 · Score: 1

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.

--
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.

Re:Formal specifications are pretty useless for th by gweihir · 2014-08-01 08:50 · Score: 1

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

--
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.

Re:Formal specifications are pretty useless for th by gweihir · 2014-08-01 08:53 · Score: 1

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.

--
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.

Re: Formal specifications are pretty useless for t by gweihir · 2014-08-01 09:15 · Score: 1

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.

--
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.

Re:Formal specifications are pretty useless for th by gweihir · 2014-08-01 09:18 · Score: 1

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?

--
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.

Re:Formal specifications are pretty useless for th by gweihir · 2014-08-01 09:21 · Score: 1

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.

--
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.

Re:Formal specifications are pretty useless for th by Anonymous Coward · 2014-08-01 09:32 · Score: 0

Says the guy throwing around big definitions as if he's some super-genius. Your buzzwords are buzzwords. Get a life.

Re:Formal specifications are pretty useless for th by gweihir · 2014-08-01 09:38 · Score: 1

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

--
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.

Re:Formal specifications are pretty useless for th by gweihir · 2014-08-01 09:40 · Score: 1

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.

--
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.

Re:Formal specifications are pretty useless for th by gweihir · 2014-08-01 09:43 · Score: 1

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.

--
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.

Re:Formal specifications are pretty useless for th by next_ghost · 2014-08-01 11:13 · Score: 1

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 by lgw · 2014-08-01 12:08 · Score: 2

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

--
Socialism: a lie told by totalitarians and believed by fools.

Re:Formal specifications are pretty useless for th by lgw · 2014-08-01 13:22 · Score: 1

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.

--
Socialism: a lie told by totalitarians and believed by fools.

Automatic ahead of time compilation by tepples · 2014-08-02 01:06 · Score: 1

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 by tepples · 2014-08-07 05:15 · Score: 1

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 by tepples · 2014-08-07 14:10 · Score: 1

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.

Slashdot Mirror

PHP Finally Getting a Formal Specification

180 comments