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

231–240 of 263 posts

Re: Announcing a specification for PHP

#231

Post by tragic »

Kiro wrote: post #209
chatmasta wrote: post #185

Earlier quoted context omitted.

... which you can also do on platforms like digitalocean. Just spin up a preconfigured dokku droplet and git push.

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

So that would be "I don't want to be bothered with two clicks and a single terminal command." Really?

Leaving aside the whole "PHP sucks" vs "PHP is great/fine for my purposes" thing, this is really breathtaking. The fact that you can just FTP up your folder does not mean that's a sensible best-practice way to deploy anything, PHP, Ruby, Brainfuck or whatever you like. It isn't. FTP is insecure[0]. If you're balking at 'git push', then presumably you're balking at source control, which involves a lot of that sort of thing. That is just entirely unprofessional.

And 'no replacement'? FTPing a bunch of stuff into a public folder allows you to deploy something quickly and easily. So does the GP's suggested workflow. It is, exactly, a like for like replacement - except that it's a more secure and less fragile workflow.

I repeat - this has no bearing on the pro/anti-PHP holy war (I lean towards anti, but there's good PHP code out there, whatever. Hopefully a proper language spec will shove things in the right direction). If your argument for PHP is that it allows you to easily evade responsible working practices in software development, however, you're getting dangerously close to the anti-PHP stereotype of the average PHP developer.

[0] http://en.wikipedia.org/wiki/File_Transfer_Protocol#Security

Re: Announcing a specification for PHP

#232

Post by wisty »

agumonkey wrote: post #57
TazeTSchnitzel wrote: post #39

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.

See https://github.com/devyn/unholy (Ruby to Python bytecode, then Python bytecode to Python source). Used to run Ruby on Google App Engine, I think.

Re: Announcing a specification for PHP

#233

Post by dragonwriter »

wisty wrote: post #232
agumonkey wrote: post #57

Earlier quoted context omitted.

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

See https://github.com/devyn/unholy (Ruby to Python bytecode, then Python bytecode to Python source). Used to run Ruby on Google App Engine, I think.

The usual way to run Ruby on GAE is just to use JRuby on the App Engine Java runtime. Unholy has been dead for years, and from the commit messages seems to have never gotten to more than very basic functionality; I doubt very much that you could run meaningful code with it, on GAE or otherwise.

Re: Announcing a specification for PHP

#234

Post by wvenable »

joepie91_ wrote: post #196
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…

Having used PHP actively for 9 years, having seen it 'evolve', and having started with a number of different languages/platforms (Python and Node.js in particular), I can say without a doubt that PHP is still awful. Yes, things are being improved. But in terms of language usability and consistency, PHP is still miles behind pretty much everything else, especially given the slow deployment of new versions of PHP. As f…

> PHP seems to treat them as entirely differerent types, which leads to something like "calling a method on it" being a technical impossibility in the current architecture.

Most platforms treat scalars as entirely different types at some level and then paper over the differences. As for the PHP architecture, I've actually looked into this, and it would take only one small change to the method-call code to add methods to scalars. In fact, the design of PHP makes this surprisingly easy to add.

Re: Announcing a specification for PHP

#235

Post by needusername »

DCKing wrote: post #116
vorg wrote: post #73

Earlier quoted context omitted.

> I am enjoying my current stack (Java8/Clojure/Groovy) 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 th…

I was untder the impression that a Java implementation that wants to call itself Java can actually call itself Java if it is made to pass specification test suites. 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.

Right, you have to buy and pass the test suites (TCK).

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.

Re: Announcing a specification for PHP

#236

Post by wvenable »

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.

A lot of languages have ways of calling functions and methods by string names -- PHP just makes it very easy and the design is actually really clean.

Re: Announcing a specification for PHP

#237

Post by TazeTSchnitzel »

chriswarbo wrote: post #220
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.

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

Re: Announcing a specification for PHP

#238

Post by Gigablah »

Daishiman wrote: post #158
Gigablah wrote: post #155

Earlier quoted context omitted.

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

That, by itself, is not trivial. Compounded with a hundred small little annoyances, it makes the code comparatively unpleaseant.

No post body was provided.

Re: Announcing a specification for PHP

#239

Post by krapp »

giaour wrote: post #221
Gigablah wrote: post #154

Earlier quoted context omitted.

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

Whenever I do use Laravel the first thing I do is swap out blade for twig. I'm pretty sure no one would use blade if Laravel hadn't decided on it.

It's weird that a framework so self-consciously dedicated to 'best practices' would ignore what's considered one of, if not the, best templating systems in PHP. Particularly given the extra benefits twig provides out of the box (automatic escaping, a function sandbox, hooks for writing your own plugins and parsers, etc.)

Post reply on HN