Announcing a specification for PHP • Hacker News Board

Re: Announcing a specification for PHP

#221

Post by giaour » Thu, Jul 31, 2014, 2:02 PM UTC

Gigablah wrote: post #154

DigitalSea wrote: post #108

Earlier quoted context omitted.

Laravel alone was enough to bring me back to PHP. It seriously has made PHP exciting again (I come from a Codeigniter and Zend background). It takes all of the things people love about Ruby on Rails and brings them to a PHP framework utilising modern features like traits alongside the fantastic selection of packages like Cashier. The even more surprising aspect of Laravel isn't how great it is, but rather the fact it…

> The even more surprising aspect of Laravel isn't how great it is, but rather the fact it was built by one guy ... using mostly 3rd party components, the majority from Symfony. So no, it's not "built by one guy".

Every time I found something I liked about Laravel, it turned out to be a Symfony component. Every time I found something I hated, there was a Symfony component that did it better.

The best example has to be the templating languages used. Blade is a weird port of ASP.NET MVC's Razor syntax and I've never understood why anyone would use it over Twig (or even just raw PHP).

Re: Announcing a specification for PHP

#222

Post by xutopia » Thu, Jul 31, 2014, 2:18 PM UTC

TazeTSchnitzel wrote: post #199

k3liutZu wrote: post #183

> PHP is definitely the lingua-franca of the internet. I think they misspelled Javascript.

PHP is on the server .

A lot of the sites we frequent have python, ruby or C# on the server.

Re: Announcing a specification for PHP

#223

Post by cglace » Thu, Jul 31, 2014, 2:33 PM UTC

colordrops wrote: post #177

randomdrake wrote: post #170

Earlier quoted context omitted.

> the only real reasonless difference is string functions are haystack / needle, whereas array functions are needle / haystack There's a trick to this that isn't too hard to remember. Searching for a value in an array is much more akin to searching for a needle in a haystack. So, for array functions, it's like searching for a needle in a haystack. For string functions, you're searching in a haystack for a needle. I'm…

> searching for a needle in a haystack > searching in a haystack for a needle wait, what's the difference?

The order of the words.

Re: Announcing a specification for PHP

#224

Post by Arnor » Thu, Jul 31, 2014, 2:37 PM UTC

DigitalSea wrote: post #113

Arnor wrote: post #79

Earlier quoted context omitted.

Fun with PHP: $a = 'b'; $b = 'a'; echo $a."\n"; >>> b echo $$a."\n"; >>> a echo $$$a."\n"; >>> b Yaaa $obj = new StdClass(); $obj->x = 1; function x_plus_one($obj) { $obj->x++; } x_plus_one($obj); var_dump($obj); >>> object(stdClass)#1 (1) { >>> ["x"]=> >>> int(2) >>> } Huh? A local change to the object changed the object outside the local scope? It must have been passed by reference... function null_the_object($obj)…

If you're going to rag on a programming language on a site like Hacker News my advice would be to make sure you know what you are on about before you do. There isn't a programming language out there that doesn't have its quirks, look at Javascript, it has more quirks than you can poke a stick at, but that doesn't make it a bad language. In your examples I am not seeing the issue? Am I missing something here? Your exa…

I don't hate PHP, I hate the fucktards who use it. (bye karma...)

Re: Announcing a specification for PHP

#225

Post by ihsw » Thu, Jul 31, 2014, 2:40 PM UTC

frik wrote: post #174

girvo wrote: post #124

Earlier quoted context omitted.

With HHVM + nginx you can really fly! Seriously, it's amazing how fast it is (and the Techempower benchmarks put it at #1 for anything with multiple requests and data handling!)

You are spot on, Nginx+HHVM is really fast. I am an early adopter of HHVM (since Dez 2012) and it really shines on sites with thousends of requests per seconds. I heard PHP 5.5+ on Nginx (FPM) is fast as well. And I prefer PHP as I can code websites without the need of frameworks (PHP is "the framework") with a C/C++ like syntax. The idea of libraries is much older than frameworks, and in the end libraries are so muc…

Using php-5.5 with php-fpm and nginx, can confirm.

There are some gotchas that you will trip over along the way, but after that it's nothing but smooth sailing.

Re: Announcing a specification for PHP

#226

Post by jfoutz » Thu, Jul 31, 2014, 2:43 PM UTC

chriswarbo wrote: post #195

jfoutz wrote: post #136

Earlier quoted context omitted.

or just distribute an upgrader with the next release. I'm sure it's more complicated than just find and replace, but the interpreter has a perfectly good parser right there. eval is impossible (or very hard), but it's pretty legit to error out in that case.

It's not legit to error-out for eval, since PHP has all kinds of eval-like things. For example, PHP has two namespaces for functions: anonymous functions live in the regular variable namespace, so they can be passed around directly. Named (AKA global) functions are completely separate, so we can't pass them around as values. For example: $my_anon = function() {}; function my_named() {} // Valid array_map($my_anon, []…

That's really helpful and insightful. I had specifically avoided mentioning dataflow analysis, I still think a lot of progress could be made with that approach. Essentially modify the interpreter to run every branch, both the true and false clauses of if, and note what strings have what value at that point of execution.

in your final example, you can replace the map with a big case switch of all known functions and an error clause.

That's of course, a lot of work. I'd guess it's just not worth it.

Re: Announcing a specification for PHP

#227

Post by ihsw » Thu, Jul 31, 2014, 2:43 PM UTC

birkbork wrote: post #10

This is great news for the PHP community, and I for one applaud their effort. Contrary to what many HN hipsters seems to believe, PHP is quite a capable language, and HHVM / Hack is really pushing things forward. * 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 pa…

PHP the language and the development environment around it is quite capable, however the unwashed masses of "developers" and the plethora of code spewed forth from them would cause you to avoid PHP like the plague.

Re: Announcing a specification for PHP

#228

Post by TazeTSchnitzel » Thu, Jul 31, 2014, 2:46 PM UTC

SaraMG wrote: post #66

TazeTSchnitzel wrote: post #11

Earlier quoted context omitted.

>Hack introduces type hinting, imo the major lacking part in PHP. Hack extends PHP's type hints, it doesn't add them. It also makes PHP statically typed.

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

It does have a fully statically and strictly-typed mode, though, and regardless of its strictness, it makes PHP fully static in strict mode, to my understanding.

Re: Announcing a specification for PHP

#229

Post by TazeTSchnitzel » Thu, Jul 31, 2014, 2:47 PM UTC

jules wrote: post #210

chriswarbo wrote: post #191

Earlier quoted context omitted.

Parameter order is an important part of a function's interface. In particular, commonly-used arguments should occur before call-site-specific arguments, so that we can specialise the function. array_map gets this right: $asBools = partial_apply('array_map', 'boolval'); $asBools(['hello', '', 'world']) === [true, false, true] $asBools([-2, -1, 0, 1, 2]) === [true, true, false, true, true] array_filter and array_reduce…

The far greater wart is passing functions as string names. PHP is so bad that it's hard to imagine that it isn't a giant troll. No amount of modernizing will ever turn PHP into anything close to sane; the amount and depth of craziness is simply too huge.

That's something I'm working on by adding function references. Not sure if it'll be accepted.

Re: Announcing a specification for PHP

#230

Post by donatj » Thu, Jul 31, 2014, 2:59 PM UTC

jules wrote: post #210

chriswarbo wrote: post #191

Earlier quoted context omitted.

Parameter order is an important part of a function's interface. In particular, commonly-used arguments should occur before call-site-specific arguments, so that we can specialise the function. array_map gets this right: $asBools = partial_apply('array_map', 'boolval'); $asBools(['hello', '', 'world']) === [true, false, true] $asBools([-2, -1, 0, 1, 2]) === [true, true, false, true, true] array_filter and array_reduce…

The far greater wart is passing functions as string names. PHP is so bad that it's hard to imagine that it isn't a giant troll. No amount of modernizing will ever turn PHP into anything close to sane; the amount and depth of craziness is simply too huge.

I feel like its callable system is simple, easy to use, and frankly awesome.

I can do $func = ['object', 'staticMethodName'];

$func = [$instance, 'publicMethodName'];

$func = 'functionName';

$func = '\namespaced\functionName';

$func = function(){ ... };

$func = $callableObject; // ( http://php.net/manual/en/language.oop5.overloading.php#objec... )

I can execute any of the above by calling `$func('doIt');`

Moreover all of those will all pass a `callable` typehint on a method call as well as the is_callable if they exist and are callable. Its quite powerful.