Hacker News new | past | comments | ask | show | jobs | submit | soc88's comments login

> $foo will grow stronger than ever.

  -- Democratic People's Republic of Korea
Yeah, sure.


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


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

There are many very, very smart people that try to teach others as a form of their own expression and learning. People coming from other programming languages that are extremely talented in that language, often take on this role as they are confident in their abilities. That doesn't make them stupid, nor should it disqualify them from attempting to teach or help others.

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

I don't think that's a fair assessment at all. In my experience dealing with precisely that situation, I find that most are actually very willing to accept and admit to their fault. Even in the chat room, over the many years I've been there, there are far more people willing to accept their incorrectness over people who take offense.


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


soc88, dude, can you stop with your personal anti-PHP agenda. You are bringing NOTHING to the table.

> - Why is the documentation in such a bad shape?

The documentation is up-to-date AND in good shape.

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

What kind of processes? The documentation clearly lays out pitfalls and problems to watch out for.

> - Why are large parts of the implementation barely maintainable?

What parts?

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

What part of the ecosystem? It seems fine to me.

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

Seriously, give me some examples of these bad practices, please.

> - Why is the language so unbelievable slow?

In comparison to what? For the class it is in, it is very fast.

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

Erm, I've run long running processes for years. There was once a problem with circular references but this has long since been resolved.

Also, you showed your lack of understanding of PHP in a previous response (http://news.ycombinator.com/item?id=4198984) to mine where you where unable to distinguish between the Apache and Cli PHP SAPIs.


> - Why is the language so unbelievable slow?

In comparison to what? For the class it is in, it is very fast.

PHP is what I would an intertwined language as quite often people don't separate PHP the language, PHP the included battery (aka the standard library), PHP the easy deployed script and PHP the web tool at core.

It's both a curse and a blessing IMHO. It easy to ignore the differences but hard to learn about them later and the official doc not really teach about it doesn't help. I am not say the doc is bad, just trading off clearly for easiness. It probably helped PHP grow so popular.

As for the quote, PHP the language _is_ slow but the mitigated by a fast standard library (mainly C function wrappers). That said, PHP 5.4 is faster than ever.


> - Why are large parts of the implementation barely maintainable?

What parts?

------------

Possibly the part that essentially required \ as a namespace separator. This was because ZE2 simply couldn't be coaxed to deal with a different separator, and no one has yet spearheaded a ZE3 to take the lessons learned over the last decade and revamp the internals to allow for more modularized growth/modifications.

Most other languages have had underlying VM changes which allow for better language enhancements. Every PHP language change in the last 12 years has had to work within the confines of the existing VM, and I've not seen any substantial changes to it in 12 years.


Thanks for your reply. I remember the ordeal on the internals list .. but what does that have to do with maintainability?


It may be splitting hairs, but I don't see anyone able to step up and address the mods necessary to ZE2 to support any new features, ever. We're basically stuck with ZE2, and we (as a community) make the best of it. ZE isn't 'maintained' actively, it just exists, and I haven't heard of any plans for an overhaul or new version. Compare that progress to the JVM and .NET CLR over the last 12 years.


I guess people are the real problem of PHP. But then again: people are the real problem of everything.


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.


That doesn't answer the question of WHY everybody should have that skill set.


  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.


I can't vote this down enough.

I have worked with a lot of people and mentored quite a few at companies I've worked at. Some were designers, some weren't even in the IT departments. Any that wanted to learn something about we programming I lead in the direction of PHP which I cut me teeth on before moving onto other things (currently Scala). They could get a dev environment up and running in no time, and better than that they could actually host something they did on shared hosting for practically nothing (or actually nothing as I sometimes gave people sandboxes in my hosting).

PHP is a gentle introduction to server concepts and have a fairly simple and not-too abstract syntax. Yes yes, when you really look at it there are some fairly glaring inconsistencies but the reality these people were not at the stage where they would notice or care.

It's also embarrassing to me as a professional who, like most, believe that some knowledge in programming will be of great use to people (in business or otherwise) and try my best to support anyone I know wanting to learn something or better themselves that this attitude is so common and outspoken with no logical justification or attempt at rational counter argument. Programming is hard. Good programming is harder, and the levels at which some of us seem to hold everyone around us (and yet somehow I doubt they hold themselves to every minute at work) are unrealistic and can push people further away than do what we should be aiming for which is bringing people in.

I'm really proud of every one of the people who stuck with learning and letting me help them and I think it's appalling to belittle their efforts indirectly with comments like this.


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


The PHP team is bad, and has very little to do with the PHP community - Anthony (I think his name is Anthony) is talking about Fabien Potencier and John Wage and Sebastian Bergmann - people who are writing great software in spite of PHP's interpreter.


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.


I think it comes down to the fact that PHP does a lot of things right, and its still more efficient all around than most other tools for the problems most people need to solve in the real world.

You can point out all the flaws, but that's like pointing out the flaws in McDonald's. Sure it's cheap food, but it's consistently cheap and there's a much larger market for cheap food than gourmet food.

Perhaps "other language" developers should start thinking of themselves as gourmet chefs. And like gourmet chefs, not many people can afford their products in the real world.


The McDonald's analogy is pretty good since you can also go to any other fast food joint or even cook for yourself more cheaply and nutritiously than you eat McDonald's.

People have sentimental feelings about McDonald's, prefer the style of fries, etc. - it isn't that McDonald's products are incomparable or irreplaceable and that the only alternative is expensive, difficult "gourmet" food.


>and its still more efficient all around than most other tools for the problems most people need to solve in the real world.

How exactly? I always see vague assertions that PHP is somehow better for "stuff I do in the real world", but nothing concrete. Guess what, the rest of the world is real too. I am not writing haskell code for my imaginary friend, I am writing it for real users to use in the real world, and a real business relies on it to provide real people with real incomes to feed their real families. How exactly would PHP be "more efficient all around"?


When I say efficiency, I mean in the economic sense. That the ratio of input it takes to develop some things in PHP is lower than it would be for other languages.


When I say exactly, I mean a precise, concrete example. I've used PHP for over a decade. I have yet to encounter a case where using it was optimal, only cases where using it was required by customer demands. That is why I am asking for a real example of something that is easier in PHP, instead of a vague "some stuff".


I honestly don't know. They're all very bright. They could add a lot to any language they programmed in. Maybe making money off of PHP is easier?



Wait wait, this Turkish bug is just under TEN YEARS OLD?


To be fair, it looks like it was fixed for a while, before resurfacing in 2006 and being ignored for the next 6 years.


How so?


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


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

I'm talking about the CLI SAPI, NOT the Apache SAPI.


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.


As for scala.


Ouch.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: