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.

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

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

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

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

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

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

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

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

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

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

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

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

Those aren't issues, they're features. Lack of static typing (odd choice of words - you could say Java lacks dynamic typing) allows much sparser code and you don't have to waste time compiling. The downside is there's more chance of runtime errors, but the time you've saved probably makes up for it and hell, you've got time now to write those unit tests.
Performance isn't Python's strong point, but there are lots of options. For example, if you want to parse XML, ElementTree has a fantastic API and is writ

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 argumen

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.

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 remind

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.

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

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.

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.

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.

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.

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 thi

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 appl

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.

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.

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.

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.

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

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 unders

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 [wikipedia.org] 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 [wikipedia.org] at all, the word "informal" is inapplicable because it's a complete

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

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.

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.

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 com

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.

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.

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.

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

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

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.

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?

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.

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

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

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/3True

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

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.

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

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 use

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 ha

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

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.

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

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!

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.