[dlitz]

Javascript is just Scheme with a C-like syntax and a limited number of bad design decisions (like automatic semicolon insertion and the == operator). PHP is a never-ending fountain of bad design decisions, because its core devs continue to make new ones.

[sharkbrainguy]

No, Javascript is not "just scheme" with a few bad design decisions. They have significant differences.

Scheme has:

  call-with-current-continuation http://people.csail.mit.edu/jaffer/r4rs_8.html#IDX509
  Tail Call Optimisation
  A numeric tower http://people.csail.mit.edu/jaffer/r4rs_8.html#SEC50
  A Code/Data equivalence and therefore macros
  Ports

Javascript has:

  Prototypal inheritance
  Every 'object' is mutable bag of string indexed properties

There's a pile of differences, even just at the semantic level before you get into the syntax or the equivalence semantics.

I understand that if you take a specific subset of javascript, you can write code as-though it has some scheme semantics (minus call/cc and TCO), but that's true to a similar extent of any language with lexical scope, closures and anonymous functions.

[wvenable]

What bad design decisions have been made in PHP in the last 5 years?

[ainsomni]

Using '\' as a namespace seperator? Just off the top of my head, there are probably loads more.

[TheBoff]

What makes that explicitly bad?

[wvenable]

I've actually gotten used to it (and I rallied against it heavily). It's really not so bad; it's even somewhat nice it has a file-system like connotation. PHP's design precluded using any existing operators.

[swivelmaster]

Based on how long it took to introduce the ability to say foo()["bar"], I'm guessing it's not the language so much as it's a set of poorly designed parser rules.

Also, magically, I can't use empty(functionResult()); but I can say $result = functionResult(); empty($result);

[wvenable]

> I'm guessing it's not the language so much as it's a set of poorly designed parser rules.

There are poorly designed parser rules but the namespace operator is not due to that. It's due to the fact that a single PHP file will be compiled to byte code without knowing what the symbols represent until runtime. The separate operator is needed because names are resolved before execution begins and before the symbols are known.

> Also, magically, I can't use empty(functionResult()); but I can say $result = functionResult(); empty($result);

Empty is identical to the not (!) operator except that empty() can operate on undefined variables, undefinted array keys, or undefined properties. empty(functionResult()) doesn't make any sense because functionResult() can never be an undefined variable. You just use !functionResult().

[batista]

really? add: floating point everywhere, objects that act like hashes but not exactly, fucked up scoping rules including global by default, the braindead Dom API, a severiously limited standard library, and brain damage coersions to the list...

[VMG]

I'd leave the DOM API out of it, that's not really the languages fault.

[batista]

Well, its the first one hat offered it, isnt it?