soc88

> People coming from other programming languages that are extremely talented in that language

PHP wouldn't be this worse if this was what would actually be happening, because these people would assess the situation and take away the control from the PHP team, due to its inability to do its job.

More realistically, people see PHP and run away screaming. The only people using PHP are those unable to see how unbelievably bad the language and its libraries are designed and implemented.

> I find that most are actually very willing to accept and admit to their fault.

- So why is the standard library in such a bad shape?

- Why is the documentation in such a bad shape?

- Why aren't there any established processes in place to prevent repeating mistakes (see above)?

- Why are large parts of the implementation barely maintainable?

- Why is the ecosystem still in such a bad shape?

- Why is the core team spreading bad practices instead of good practices?

- Why is the language so unbelievable slow?

- Why is the runtime and the garbage collector of such bad quality that it is completely impossible to run sufficiently complex applications over a larger period of time?

> $foo will grow stronger than ever.

  -- Democratic People's Republic of Korea

> there are many self-described experts in PHP

I think this is the real problem of PHP.

It attracts people too stupid to realize that their own level of knowledge should make them avoid teaching others.

As soon as someone points out an issue they almost immediately switch to "LALALALALA I CAN'T HEAR YOU!!!".

Everybody should have basic programming skills, just like math, writing, etc.

That doesn't mean we have to be happy with the shitty way things are currently done.

  Smoking isn't just a profession, it's an everyday skill
  that everyone should learn, regardless of how badly. 
  A cigarette is a great enabler for this - and I endorse 
  this direction completely.

  -- Your friendly tobacco association.

The question is why they don't move on to a working language, knowing that the PHP team will _never_ fix all these bugs. It is like those people who keep penny-stocks they bought years ago for a lot of money, trying not to realize that their investment is worthless now.

> The core of the PHP community is filled with a lot of really talented and smart developers doing some really amazing things.

Like those, who failed for years to actually consult the results of the test suite before shipping a new release? http://gcov.php.net/viewer.php?version=PHP_5_4

Like those who change stuff incompatibly to the worse, while introducing security holes? http://php.net/manual/en/function.is-a.php https://bugs.php.net/bug.php?id=55475

Like those were security fixes create even larger holes? http://thexploit.com/secdev/critical-php-remote-vulnerabilit...

Like those who can't program a sane line of code in the language PHP is written in? "OMG, this calculation overflows, let's replace the int by an float!"

You can't make that shit up. I have nothing against stupid people, but against stupid people who fight against every kind of process who could prevent their own stupidity like

- "learning from mistakes",

- "learning the language they actually program in",

- "handling bug reports in a way it doesn't alienate reporters" or

- "having a decent test coverage".

Instead of thinking about yet-another-documentation site, what about fixing the devastating quality of their API documentation (especially the comments)?

Yes, the daemon. The actual interpreter is still thrown away every few requests, because it is leaking memory like hell.

I hate this apologist bullshit. Yes, we know that there are a lot of PHP sites on the net, we aren't retarded.

If PHP wouldn't be such a wide-spread problem, people wouldn't have to spend so much time fighting against it.

One positive thing: His post was didn't kill my spell checker, that's an impressive achievement for a PHP developer. You don't see coherent sentences that often from those people.

Weren't there quite some different templating choices (including Groovy) available from the beginning?

Independently from that, the compilation times will automatically improve when they update a) their SBT version and b) their Scala version. Additionally, Play developers can also refine their own code.

It's funny how that "functional" name calling appears so convenient if it fits the own argumentation. (Not considering that Scala is foremost an object-oriented language.)

Groovy is trying to play catch-up with Java currently (typing-wise) and I don't see how they will implement a modern type system in the next decade with the amount of cruft they have accumulated since Groovy's inception.

Additionally, Java 8 will ship with closures, so I'm not seeing where a niche for Groovy will remain.

Ouch.

You mean the dormant one from 2004 which was never finished? http://jcp.org/en/jsr/detail?id=241

Or the "Groovy specification" which is almost completely empty? http://groovy.codehaus.org/jsr/spec/

This is my impression, too. I think Groovy's "static" features are a reaction to a lot of developers realizing that "statically typed" doesn't necessarily mean that the language has to be as cumbersome and verbose as Java.

Imho, there is just no reason for building/using/preferring a dynamically typed language, except when the language designer lacks the necessary abilities to build a sound and coherent type system.

Scala has none of Groovy's drawbacks, a lot of benefits combined with a clear roadmap -- and most importantly: The determination to not only get something working, but also to get it right.

Meanwhile, the language gets more consistent and polished with every release.

As far as I know they still lack even a language spec.

That's exactly the issue I'm talking about: you can't “enforce” the static type, so different methods get called depending on whether you pass List foo = MyList(...) or MyList foo = MyList(...), which is acceptable for static methods, but a source of bugs when they can be made to look like instance methods.

> Scala has some neat stuff, but it's not Java 8 so I don't see how it's relevant.

Java's default methods are basically Scala's traits (just made a bit more cumbersome to make Java developers feel right at home), so what I said about traits applies to “interfaces with default methods”, too.

Just wanted to say thank you for this great list!

Could you please tell me in which alternative reality you live in? :-)

> Functional programming style tends to generate lots and lots of objects which die very young.

Well, there is a lot of Scala code out there doing exactly that.

HotSpot has no problems with short-lived objects in pretty much all its garbage collectors while Dalvik's GC is just a lot less sophisticated and mature.

So I mainly agree with you, but the proposition of

      Language allows producing lots of short-lived objects
    + Dalvik sucks
      ------------
      Programs in that language have to be slow

> I may also be missing the point but what prevents you from putting a count method on an enumerable with a default implementation which does the same?

Isn't that exactly what we're talking about?

The huge difference between C#'s extension methods and traits is that the first one is statically dispatched, the second one dynamically.

This means classes with a better implementation can just override Count() and suffer none of the problems of the extension method approach.

Scala also offers implicits to "enrich" existing types, slightly comparable to Extension methods, but a lot more general.

Whereas extension methods only support some ad-hoc "addition" of members to existing types, Scala's implicits allow you to use these methods to implement new interfaces -- and isn't that the reason why you add methods in the first place: to implement interfaces?

> So for a (poor) example you might extend float so you could convert an angle to a 2d unit vector, but only in given bits of your program you want to be converting between angles and vectors.

   implicit def floatTo2DUnitVector(angle: Float) = 2DUnitVector(...)

Btw, C# has some limited form of implicits, too, but I haven't seen any serious usage of them for a while.

Works without problems in Scala. Maybe Clojure isn't using the available resources efficiently enough?

> The original vision behind OOP wasn't at odds with functional programming.

This!

Imho, Scala shows very well that OOP and FP can be unified without much problems, if enough care is taken.

You're missing the point. The problem is that as an author you have to implement an interface which is probably completely unrelated to what your class is doing, otherwise you get punished by bad performance.

Scala solves this problem nicely with traits, btw.

Seeing how Java tries to play catch up currently, this reads down-right bizarre. :-)

“Patching up” would suggest that they actually improved the situation.

If you had read the diff you would realize they did not.

Lots of companies missing there. I hope this stuff gets updated when the new site is up.

This also amazes me too. The US has neither a working, efficient health care nor education system, but blames others for "socialism"?

I thought the mods alone do that pretty well already?

So what? It isn't better in the US, it's just more acceptable to you.

Isn't this exactly what the article said?

> I escaped from poverty because I am significantly above the average intelligence level and I managed to make the right decision at the right time.

LOL. Dunning-Kruger comes to mind.