EDIT: i totally agree that the standard functions are a complete mess in PHP. But they have to stay around for backwards compatibility. Have a look at the SPL classes: http://php.net/manual/en/book.spl-types.php

For example, how would I make a string abstraction? Create a class? Ok, so we have:

$str = new String("foo") $str->replace(...)

over

$str = "foo" str_replace($str, ...)

This is fine, if we ignore the fact it's much slower.

Where it really gets annoying is PHP's lack of operator overloading. That means to concatenate I'd need to do

$str->concat($str2)->concat(new String(" "))->concat($str3)

instead of

$str . $str2 . " " . $str3

There's things you can do to make the API a little bit more convenient (i.e. allow it accept PHP strings, etc.), but ultimately it becomes a huge pain, especially if you want to start interoperating with other libraries that are using a different abstraction or, more likely, using the regular PHP types and functions.

    "foo".replace('oo', 'ood') + " tasty"

> $str->concat($str2)->concat(new String(" "))->concat($str3)

> instead of

> $str . $str2 . " " . $str3

Erm, no you wouldn't. What's wrong with either of these?

    String::implode($str1, $str2, new String(" "), $str3);
    String::sprintf("%s%s %s", $str1, $str2, $str3);

Personally, I'd prefer operators to have function equivalents, so your example could be written:

    array_reduce([$str1, $str2, " ", $str3], '.', "");

This is not PHP, this will never be PHP. Some people need to remember the purpose for which PHP was started and what it still is great at: making websites.

You guys are stuck in high brow academic debate on the semantic of a language that was born before many of us started coding, and that helped the web become what it is today. And that has come a long way.

I'm not saying to stop improving the language, but as someone who has used PHP for 15 years, all the issues I see come up constantly in threads like this are non issues, never encountered them in any web situation, you have to seek these "bugs"/annoyance, or be seriously inexperienced with PHP, or as I've been saying for years any time I do conferences: you are using PHP wrong.

So please, keep your verbose syntax in other languages that "need" it, while there are improvement to be made on PHP, this is not an area that needs one.

Also, looking at your bug submission/request, I share krakjoe sentiment: what the F are you trying to achieve? Seriously, I am curious. To me it screams wrongly used PHP.

Of course it's wrongly used, since it doesn't work (hence my request to make it work).

The issue is not whether we should write such code now (we obviously shouldn't, since we'll hit all kinds of language problems); it's whether we'd like to write such code in the future (in which case we need to fix those problems now). Personally, I would like to avoid redefining built-in capabilities over and over.

As for what I'm trying to achieve, the same as everyone else: clean, understandable, maintainable code.

Here's something I ran across this week. I'm instantiating a class $class (read from a config file) and need to inject dependencies ($dep_classes, read from a config file) into the constructor. How to do it?

    $deps = [];
    foreach ($dep_classes as $dep_class) {
      $deps[] = new $dep_class;
    }
    $instance = new $class(...$deps);

    $deps = array_map(function($dep_class) { return new $dep_class; }, $dep_classes);
    $instance = new $class(...$deps);

However, it's clear that, again, we're reinventing the wheel. array_map passes the class names to its callback, so why are we passing them to "new" ourselves?

    $deps = array_map('new', $dep_classes);
    $instance = new $class(...$deps);

- Use a foreach loop to duplicate the functionality of array_map. - Define a new function which behaves exactly like "new".

Perhaps 15 years with PHP has given you a "gut feeling" to avoid programming styles which will inevitably run into problems; I've certainly got such a feeling after 4 years. While avoiding those problems is useful to get a job done today, it would be even better if we didn't have to worry about them tomorrow.

There's no point adding features like array_map, anonymous functions, etc. to the language if we all have to learn to avoid them to avoid parser errors.

You'll be giving PHP devs a loaded gun by allowing them to register primitive types (as proposed by nikic). Most frameworks would add to them, but I know some people would change default behaviour to 'fix' issues such as db character encoding issues which would make debugging hell.

* Hack introduces type hinting, imo the major lacking part in PHP.

* HHVM introduces speed to php. On a personal project calculating perlin noise, I got about 8x speedup on HHVM.

* The specification helps pave the way for more implementations of PHP.

This attitude really frustrates me. I'm a developer with over 20 years of experience. I don't use PHP because (a) I have had poor experiences with it in the past, (b) I am enjoying my current stack (Java8/Clojure/Groovy), and (c) would go with stacks like RoR over PHP if I had to choose, simply because I've had good experiences with Rails.

You're implication that this has something to do with trendiness is frankly insulting.

I don't think you're one of those.

I'm afraid they're going to have to show me reasons it's actually superior to other languages before I'm going to jump on the train. This "it's less broken than it's ever been" stuff isn't going to cut it.

One thing that makes me chuckle every time I decide to give PHP a fair glance again is "<?php" at the beginning of all the source files. It's hilarious to me that with all the well understood best practices about separation of logic and presentation, people are still seriously using a language where you have to use a little signal to the compiler that means "ok, here's where the HTML stops and the code begins!" I assume at this point it's a vestigial tail, but it's just one irritating reminder that this language was originally designed for half-ass hacks.

If you're going to harp on the most unbelievably trivial things, no, you never intended to give it a fair glance.

Compounded with a hundred small little annoyances, it makes the code comparatively unpleaseant.

I myself use (besides PHP) C#, Javascript, Python, and recently revisited C++ to check out C++11 (I am thrilled). I have been working developing in mainly PHP since 1999 so I have seen most of it's ugly sides.

This thread however was about PHP, not wether Java is good or bad.

Not just trendiness, but also whether a spec exists, from which alternative implementations can be reliably built. Some language despots (e.g. Python's) have even had moritorium periods of no new features specifically to help other implementations catch up. The spec announcement is a step forward for PHP.

Your current stack is at widely varying extremes along the spec continuum:

* Java 8 is fully spec'd to intricate detail, and Java has implementations other than Oracle's. Anyone can build an implementation as long as they don't call it Java.

* Clojure is informally spec'd by the comments in the functions, and what little grammar there is is explained on the clojure.org website. Alternative implementations exist to varying degrees of compatibility, e.g. ClojureScript doesn't have native macros.

* Groovy has virtually no spec at all after 11 yrs. Despite it being spec-driven at first, its JSR was inactive for 7 yrs, then changed to dormant status 3 yrs ago. My personal experience is the Codehaus project management actively prevent other implementations being built.

There is currently one major Java(-like) implementation that does not do that, and that is the variety that runs on Android. But there are plemty of other Javas that call themselves a Java.

The thing with Android is they are not close passing the test suites (AFAIK Harmony was close but Android is only a fraction of Harmony).

Compare what Android implements: http://developer.android.com/reference/packages.html And what they would have to implement: http://docs.oracle.com/javase/6/docs/api/ Of course the difference is even bigger for newer Java Versions (NIO.2, Date Time API, Fork-Join, …).

In addition I believe the linking semantics in Dalvik are slightly than in Java, eg. slf4j needs a special version to not fail during dex translation.

I'm not sure whether there is actually an official Java implementation that does not have a license of the implementation from Sun/Oracle or uses OpenJDK. If not they would have to reimplement all of the classes including AWT/Swing. Azul for example does have a license for Zing. I'm not sure if IBM already builds on OpenJDK.

Seriously, calling people out merely for their account age? Really? You really think that's a valued contribution? I mean, your comment amounts to nothing more than a weakly flung insult.

HN hipsters dislike PHP.

Divining which is which from posts is a dicey proposition.

I'm not a web-developer (or whatever you would classify PHP as), so I don't feel hit with the remark.

"Hipster" is a term commonly used to describe those who advocate so-called "Web 2.0" technologies like Ruby on Rails, JavaScript, HTML5, NoSQL, and so on. These people openly admit that they dislike the previous generation of web development technologies built around languages/platforms like Perl, PHP, and Java.

There are many of those people here, so it makes sense to refer to them collectively, especially given their typical stance toward PHP. Asking them to revisit their current state of PHP is a reasonable enough request.

Now, "hipster" is also often used as a derogatory term, too. It's quite understandable, after dealing with some of those kind of people. But I don't think it was used in that sense in the earlier comment.

I don't think anyone is complaining that it's not turing complete (or whatever), it's all the times php has dropped the ball in the std library, both with respect to being consistent with itself and just being plain broken. I don't think any sane person would switch from a language INTO php, given how many languages that are just as capable as php without having all of its various historical burdens (sigils, stdlib, mediocre type system).

It has never been about whether PHP can get shit done, it's that given languages that actually had formal design processes and make your days as a coder a joy, why would you move TO PHP.

There are simply so many other options.

The barrier to entry is higher if you want to run a site on something else.

That is the sole reason PHP is as popular as it is and part of the reason why it stays popular and powers so many of the internet's top websites.

Other reasons why it stays popular is that they really have improved it a lot over the years and knowledge on how to run PHP at scale is quite easily available. The community is improving along with the language.

Yes, the standard library is frustrating but that is a pretty minor inconvenience honestly. Every language has a frustrating part of its design. This wart on PHP can be fixed and there are some great recommendations on how to transition to a better std lib in other comments on this OP.

What is this really an issue for? I mean, sure, there may be more choices of low-cost low-feature shared hosts that support PHP than other languages, but its hardly as if there aren't a sufficient quantity of low-cost (even, in some cases, with free tiers) platforms for apps in a wide variety of languages.

Unless you are literally compelled to choose a host at random, the fact that a randomly-chosen shared host is more likely to support PHP shouldn't really matter.

So, choose the language based on the ease of the first 15 minutes of your startup?

That's the lesson I'd love to see other ecosystems learn. PHP, by being very novice-friendly, has developed an enormous user base. How much better off would those people be if they had started with a language that was awesome not just for starting, but for the long term?

(As an aside, I'm throwing no stones here. My first programming language was BASIC, and it took me a long time to unlearn the bad habits it gave me.)

I don't personally enjoy programming in PHP but the way people act as if it isn't massively important strikes me as obtuse and/or petty.

It's really more about the talent of your team than the language you choose to write your app(s) in.

If you have a talented team, why on earth did you choose PHP?

It isn't the late 1990s any longer. Perl and PHP aren't the only viable options available for web development. We have more alternatives now than ever before.

It was one thing when a team chose to use PHP because it was all that their preferred hosting provider supported, for instance, but those days are long gone. There really is very little reason to use PHP these days, especially for new development.

I have a team with java/php/javascript experience. PHP will not be an option for my use case. I need a json based rest interface with a decently discoverable web interface. Java has stupidly powerful rest interface libraries with jersey or full application servers, and javascript has hugely powerful frontend interfaces with angular or other frameworks, based on a strong rest interface. And the strong rest interface goes right back at java.

And we are just a limited team with java* experience. I don't know what teams with django or other twisted libraries will do, or what ruby shops will do. The era of "just make it easy to print html" is gone.

https://github.com/dingo/api

edit: I misunderstood your post I think.. But if you're looking to generate APIs, Dingo is still worth a look just for reference.. :-)

php has apigility for this.

Though if you don't have php experience I wouldn't switch languages to get it

https://apigility.org/

There are many things that they language has had to fix, and some that still need to fix. But I honestly don't feel that the direction in which the language is headed is encumbering the language further.

However, age isn't why it's got so many sharp edges. That's Rasmus' fault, and the core team's.

I can't think of a language that has out of box adoption for web development similar to PHP.

Hack extends PHP's type hints, it doesn't add them. It also makes PHP statically typed.

PHP does not have type hint for their internal datatypes (int, float, string). Only array is supported. Type hinting for your custom datatypes is supported, when used as function arguments.

Also hack introduces type hint for function return type.

I disagree. PHP finds this perfectly acceptable:

    class Foo {}
    class Bar {}
    function foo(Foo $x) {}
    function bar(Bar $x) { foo($x); }

Crucially, static types can be erased before execution without affecting the behaviour of a program: http://en.wikipedia.org/wiki/Type_erasure

How can a language be statically typed when the instructions telling it what code to use are dynamic?

Also, I don't see how pausing execution and re-invoking the compiler at run-time to load the rest of the code base (which you can do in PHP with a conditional include, don't know about Hack) can't be done with static typing.

file1.hh:

    <?hh
    $giveMeAnArray = (time() > 1)? function(array $x) {}
                                 : function(stdClass $x) {};
    $anArray = [];

    <?hh
    $giveMeAnArray($anArray);

    <?hh
    list($f1, $f2) = (time() > 1)? ['file1.hh', 'file2.hh']
                                 : ['/dev/random', '/dev/random'];
    include $f1;

    if (time() > 1) $anArray = new stdClass;

    include $f2;

- HHVM will compile file3.hh. This phase doesn't know what $f1 or $f2 will be, or whether $anArray will become a new stdClass, since they depend on the output of time().

- HHVM finishes compiling file3.hh

- HHVM will execute file3.hh, setting $f1 to 'file1.hh' and $f2 to 'file2.hh'.

- HHVM will compile file1.hh. This phase doesn't know what $giveMeAnArray will be, since it depends on the output of time().

- HHVM will finish compiling file1.hh

- HHVM will run file1.hh, defining $giveMeAnArray = function(array $x) {} and $anArray = []

- HHVM will resume running file3.hh and set $anArray = new stdClass

- HHVM will compile file2.hh, which contains a type error. How does it know?

The most likely answer is that type information is stored in values and checked during usage. That is not static typing, it's 'dynamic typing' (tag-checking).

There is an alternative possibility: the state of the compiler could be preserved between files, so type information from file3.hh and file1.hh is available when compiling file2.hh. However, this information wouldn't include knowledge that "$my_account = new stdClass" has been executed, since that's dynamic run-time information which is only knowable after file3.hh and file1.hh have finished compiling.

There is no way (to my knowledge) that interleaving static type-checking with dynamic execution can produce a type-error when file2.hh is compiled. The type-checking must have access to the execution state of the program, ie. it must be dynamic.

If type-checking happens during/alongside/interleaved-with execution, the compilation phase (which must be done prior to execution) cannot know the types of the code it's compiling. Without this knowledge, the first unit of code it produces is forced to use dynamic types (AKA a unitype). Once that unit is type-checked/executed, the runtime information gained may be used to partially-inform subsequent compilation, somewhat like a JIT, but there would always need to be dynamic fallbacks. Of course, a dynamic fallback defeats the main point of using static types: being informed when there's an error. There may be incidental benefits from doing this though, like faster code.

It makes it gradually typed. The types are only as static as you choose to make them.

The debian package maintainer of ffmpeg was/is one of the libav guys and decided to replace ffmpeg with libav. Judging by several frustrated comments in this thread, it has obviously been a hurtful decision.

There are a few writeups of the situation on the web, here's one: http://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html

A package called "ffmpeg" has been in debian forever now, and running it's binary claims that "ffmpeg is deprecated", which is a complete lie.

EDIT: also see "FFmpeg and a thousand fixes" [1], suggesting that FFmpeg is working hard improving the security situation, while libav mainly ignored the effort.

PPS also i dont like the libav crew

1: http://googleonlinesecurity.blogspot.se/2014/01/ffmpeg-and-t...

I hadn't been keeping up with ffmpeg development or the debian packaging scene, so that message caught me completely by surprise and threw me for a loop. I spent a good 10 minutes on google trying to first figure out why ffmpeg was being deprecated, and then trying to figure out why debian was lying to me.

Ubuntu as well. That immediately made up my mind never to use libav. Incredibly unprofessional since 90 seconds of googling turned up the fact there was a fork and a dispute.