Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Announcing a specification for PHP

hhvm.com

Post reply on HN
Print view View original

241–250 of 263 posts

Re: Announcing a specification for PHP

#241

Post by grandsham »

will_work4tears wrote: post #217
Kiro wrote: post #209

Earlier quoted context omitted.

> Just spin up a preconfigured dokku droplet and git push. Exactly the kind of things I don't want to be bothered with. I'm just saying that traditional web hosts suit my needs perfectly and DigitalOcean is no replacement.

That workflow is pretty outdated, you know. It's about akin to using tables for layout, and about as much of a no no. I know, git can be pretty confusing, but using version control, even in a one man shop, is a huge boon.

who says Kiro isn't using version control?

traditional web hosts provide a level of management that isn't present in VPSes. You may be able to get turnkey instances, but you still have to be responsible for managing them and maintaining them. Vs a traditional webhost where you don't have to worry about all that.

You can claim that its "outdated" and "akin to using tables for layout", but its also still a very valid workflow for a lot of people who don't want to be sysadmins in addition to developers

Re: Announcing a specification for PHP

#242

Post by chriswarbo »

TazeTSchnitzel wrote: post #237
chriswarbo wrote: post #220

Earlier quoted context omitted.

> It also makes PHP statically typed. I disagree. PHP finds this perfectly acceptable: class Foo {} class Bar {} function foo(Foo $x) {} function bar(Bar $x) { foo($x); } PHP is clearly checking types (actually, class tags) at runtime, every time a function/method is called. That's dynamic typing, not static typing. Crucially, static types can be erased before execution without affecting the behaviour of a program: h…

I meant that Hack is statically-typed, not PHP. PHP is obviously dynamically-typed.

Hmm. Looks like Hack still includes files based on strings: https://github.com/hhvm/hack-example-site/blob/master/index....

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

Re: Announcing a specification for PHP

#243

Post by TazeTSchnitzel »

chriswarbo wrote: post #242
TazeTSchnitzel wrote: post #237

Earlier quoted context omitted.

I meant that Hack is statically-typed, not PHP. PHP is obviously dynamically-typed.

Hmm. Looks like Hack still includes files based on strings: https://github.com/hhvm/hack-example-site/blob/master/index.... How can a language be statically typed when the instructions telling it what code to use are dynamic?

include "foobar.php", IIRC, is executed at compile-time, and I assume must be in Hack's type checker too.

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.

Re: Announcing a specification for PHP

#244

Post by debaserab2 »

DigitalSea wrote: post #178
debaserab2 wrote: post #137

Earlier quoted context omitted.

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.

What makes you think I don't use Rails? I use whatever I think fits the purpose at hand. I sometimes use Rails for a project, sometimes I might use Node.js and other times I'll use PHP. It all depends on different factors like budgets, time, the task and team (if any). Frameworks and languages are a lot like databases. They all achieve the same thing, they're just all slightly different and good for different purpose…

So Laravel is a lot like Rails, but it doesn't compare to Rails because it's not matured yet. Ok..

MySQL vs PostgreSQL vs MongoDB vs Neo4j are all data stores with very different principles and goals. To say they all "achieve the same thing" is like saying an airplane is the same as a speedboat because they both get you from point A to point B.

I certainly believe that frameworks and libraries are tools for different problems and there isn't a one size fits all approach, I just have trouble discerning what problem Laravel is solving better than other frameworks or what makes it advantageous to use.

Re: Announcing a specification for PHP

#245

Post by mike_hearn »

Dewie wrote: post #148
Pacabel wrote: post #140

Earlier quoted context omitted.

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…

> The presence of some quirks isn't the issue. Of course every programming language has some. It is a very weird argument that often comes up when discussing programming languages - "Lang X is weird/stupid in some ways, but no language is perfect, so it's fine and there is no reason to call it out." So, because nothing is perfect (almost by definition), it apparently isn't a big deal that some things are weird/dumb/b…

Exactly. The trend in modern languages is to try and eliminate as many surprising quirks as possible. If you look at Kotlin, it's basically advertised as resolving around half of the famous Java Puzzlers. And those puzzlers were themselves introduced by the authors with the proviso that Java has remarkably few quirks for something so very large, and that this is/was tremendous progress.

Re: Announcing a specification for PHP

#246

Post by Dewie »

Dewie wrote: post #148
Pacabel wrote: post #140

Earlier quoted context omitted.

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…

> The presence of some quirks isn't the issue. Of course every programming language has some. It is a very weird argument that often comes up when discussing programming languages - "Lang X is weird/stupid in some ways, but no language is perfect, so it's fine and there is no reason to call it out." So, because nothing is perfect (almost by definition), it apparently isn't a big deal that some things are weird/dumb/b…

I'll stress that I was agreeing with Pacabel, which might not be apparent from looking at the quote I chose to use in isolation.

Re: Announcing a specification for PHP

#247

Post by mreiland »

cdmckay wrote: post #115
mreiland wrote: post #112

Earlier quoted context omitted.

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.

I would like to think that in any sane project they would choose one of the namespaces and stick with them. Moreover, I think that as you deprecated the older namespaces, this problem would go away. You could make the exact same argument with removing register_globals: half the project using it, while half the project using the superglobals. Clearly there'd be some pain, but I don't think it would be as bad as you're…

because you're involved in a strawman. funny how that works.

Re: Announcing a specification for PHP

#248

Post by mreiland »

bitwalker wrote: post #138
mreiland wrote: post #112

Earlier quoted context omitted.

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 iss…

if it aint broke, don't fix it, and PHP's stdlib aint broke. It just aint perfect. It will never BE perfect.

And that's ok. There's a million things I'd like to see before people start trying to "fix" an stdlib that's been around for so long.

Re: Announcing a specification for PHP

#249

Post by mreiland »

59nadir wrote: post #180
maaaats wrote: 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…

> 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. Criticism doesn't become unfounded because things become better. Things become better because of criticism.

things do not merely become better because of critism, criticism becomes worse as things get better.

https://www.youtube.com/watch?v=b5I94bT23cQ&t=1m34s

Re: Announcing a specification for PHP

#250

Post by jules »

donatj wrote: post #230
jules wrote: post #210

Earlier quoted context omitted.

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 al…

The problem is that a function is a thing. A string is a different thing. Imagine if arrays were represented as comma delimited strings, and you had a function isArray to check if a string has the right format to represent an array. That would be ridiculous right? An array should be its own type. The same goes for functions. Representing functions as string names is just as crazy as representing arrays as comma delimited strings.

Though who am I kidding, PHP is also confused between numbers and arrays and strings, so I guess at least it's consistent that the language is thoroughly crazy.

Post reply on HN