Live data from Hacker News

Announcing a specification for PHP

hhvm.com

131–140 of 263 posts

Re: Announcing a specification for PHP

#131
post #23

After recently having to work with modern PHP, I have to say a lot of the criticism of the language is unfounded. It's changed a lot since I first used it. But the stdlib is still hard to manage. Different naming conventions, different order on the parameters for functions that do almost the same thing, and every function is global. Couldn't they keep all that for backwards compatibility, but create more sane wrapper…

The last goddamned thing I want in what is fundamentally a string-spitting language is to have the string features wrapped. Do what you will with the rest of the modules, but leave the damned strings alone.

"Foo".replace("o","O");

Not a big deal.

Re: Announcing a specification for PHP

#132
post #34

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…

> Contrary to what many HN hipsters seems to believe, PHP is quite a capable language, and HHVM / Hack is really pushing things forward. 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 ch…

Meanwhile, that user presumably has the impressive track record of 2 days of posting on HN, making him/her a true expert on the HN crowd.

Re: Announcing a specification for PHP

#133
post #7
post #4

As a discussion of any programming language grows longer, the probability of a bashing against such language approaches 1. Any similarity with Godwin's law is mere coincidence.

There are languages that everybody hates, and then there are the languages nobody uses.

And then there is C#. (implication being that I almost never see anyone hating on C#, and yet C# is really used a lot, obviously. Hey, I was probably gonna have to add this part to the post as an edit, anyway; might as well get it out of the way.)

Re: Announcing a specification for PHP

#134

Rookie question, but what does a language specification for PHP do or mean? I assume this is good, but don't know why. :)

What is a language, really? It's not really an implementation (necessarily); a language can have multiple implementations, in which you have to ask "which one is the language?" if they have subtly different behaviour.

In order to enforce what a language is, you can introduce a specification. This will say that "given a program X, the language will behave like Y". Now any implementation of the language can be checked for conformance.

The spec itself might be some document, or perhaps just a "blessed" implementation ("the implementation is the spec").

Re: Announcing a specification for PHP

#135
post #92

Earlier quoted context omitted.

> none of which enjoy the ubiquity of PHP (as far as being installed on such a vast majority of hosts). So, choose the language based on the ease of the first 15 minutes of your startup?

I'm talking about people who need websites in general. Not your fancy startup. Also please name me a single startup that for some reason could not flourish using PHP as opposed to some other language? It's really more about the talent of your team than the language you choose to write your app(s) in.

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

Re: Announcing a specification for PHP

#136
post #37
post #23

After recently having to work with modern PHP, I have to say a lot of the criticism of the language is unfounded. It's changed a lot since I first used it. But the stdlib is still hard to manage. Different naming conventions, different order on the parameters for functions that do almost the same thing, and every function is global. Couldn't they keep all that for backwards compatibility, but create more sane wrapper…

I thought something along the lines of keeping the existing global namespace mess but also add in namespaced, consistent aliases like you've suggested, i.e. myStr.replace() As the new ones get more use, slowly deprecate and remove the original global namespaced functions, in the same way they phased out register_globals

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.

Re: Announcing a specification for PHP

#137

Earlier quoted context omitted.

The Laravel framework[1] is a good place to start, it's quite well designed and elegent. It requires at least PHP 5.4. [1] http://laravel.com/

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…

If you like it because it's like rails, why not just use rails? The rails ecosystem is undoubtedly stronger than laravel's, and it's a more mature framework. I don't see where laravel fits in the spectrum of PHP frameworks.

Re: Announcing a specification for PHP

#138
post #37

Earlier quoted context omitted.

I thought something along the lines of keeping the existing global namespace mess but also add in namespaced, consistent aliases like you've suggested, i.e. myStr.replace() As the new ones get more use, slowly deprecate and remove the original global namespaced functions, in the same way they phased out register_globals

right, and then it becomes even less readable because someone calls in the namespace somewhere and half of your project uses 1 version, half the other. No, just stick with the consistency of using the stdlib as is. If someone really has a problem with these specific issues they don't need to be developing, period.

It's in the nature of developers to care about API design, which is really what this is about. Would you want someone to design an API for your software product that does so as haphazardly as the PHP standard library was designed? Probably not. It's only natural that people want to discuss why it's bad and how it could be fixed. I would be more concerned if you were a developer and didn't care about these kind of issues.

Re: Announcing a specification for PHP

#139

Earlier quoted context omitted.

Nikita proposes methods on primitive types: http://nikic.github.io/2014/03/14/Methods-on-primitive-types... Myself, I like this proposal.

Soon all dynamic languages will be one. Except for the method call syntax.

You mean all dynamic languages are Lisp?

Re: Announcing a specification for PHP

#140
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…

The presence of some quirks isn't the issue. Of course every programming language has some.

PHP and JavaScript, however, have unjustifiable quirks with some of their most basic functionality. We're talking about stuff as basic as their comparison operators being quite broken, for example. That's where the problem is. Furthermore, the fact that these issues have been around for well over a decade or more without being properly addressed just makes the situation even worse.

Compared to other mainstream languages like C, C++, Java, C#, Python, Ruby and even Perl, both PHP and JavaScript are quite inferior in many critical ways. Perhaps things will improve over time, but we really haven't seen that happen so far.

So let's not pretend that they're "good" just to be politically correct or to try to avoid offending anyone. PHP and JavaScript aren't good languages, and they won't really improve until their communities admit that there are some very serious issues, and then commit to getting them resolved properly and rapidly.

Post reply on HN