Live data from Hacker News

Taking PHP Seriously

slack.engineering

591–600 of 673 posts

Re: Taking PHP Seriously

#591
post #265

Earlier quoted context omitted.

> PHP is perhaps one of the easiest technologies to scale horizontally, because of its statelessness. PHP is no more stateless than any other language out there. Statelessness is a design choice, not something PHP gives you for free. If your app write things on the local disk or use the default PHP session handler then it is not scalable by default. In order to write code that scales you need to make it scalable, it'…

I would argue that PHP is more stateless than Node, for instance. Things that happen in previous requests do not affect following requests in PHP, unless you're explicitly using shared state. That's not the case in node, it isn't the case with most Java HTTP server implementations, and it wasn't the case in Rails back in the day (don't know how it is now).

I'm pretty sure PHP supports sessions. I am missing something?

Re: Taking PHP Seriously

#592

Earlier quoted context omitted.

> I am trying to write a code that is readable and maintainable instead of building complex abstractions. My point is that what's "readable and maintainable" depends on the language; especially on what facilities it provides, and to some extent community consensus (what's 'idiomatic'). Javascript's main facilities are first-class functions with lexical scope, lightweight key/value mappings (which it calls "objects")…

> For example, Javascript's objects are so lightweight that it's idiomatic to write them inline exactly where they're needed, like 'foo({bar: function() { ... }, ...})'. Idiomatic doesn't mean maintainable and scalable. Imagine you are working on a project in a team, not alone. How do you understand what kind of "lightweight" object you should pass to this function: function foo(data) { .. } When you have thousands o…

>How do you understand what kind of "lightweight" object you should pass to this function

...and this is where well-documented interfaces come in.

>but I don't understand what is the meaning of SuperUser being inherited from some user charlie.

That was merely an example to express the difference: the idea is, instead of writing a class and doing things that way, objects are cloned from one another. If you want to create a user with special powers, you clone the user object (usually running a constructor function along the way) and give it whatever new functions you want. If you want to create more of these special users, you make them all have that one as a prototype. Typically, the prototype object is never actually used or altered from the defaults, as this would be confusing, and is given a constructor function to instantiate state. But it doesn't have to be.

>I think JS was supposed not to have any inheritance at all. The objects were supposed to be created with constructors and that is all.

Wrong. Object.create may be new, but prototypical inhertance is an important par of how the constructors you claim to be the way objects were meant to be created work. Function.prototype, the property which determines the prototype of objects created by a constructor, dates back to ES1.

>I also guess JS doesn't have classes because it was designed for writing simple form validation scripts and not large applications.I also guess JS doesn't have classes because it was designed for writing simple form validation scripts and not large applications.

Also complete nonsense. Prototypical inheritance was originally implemented in Self, a system developed my Sun Microsystems, and a descendant of Smalltalk-80, which certainly was designed for large applications. JS may have been built for writing simple for validation scripts, and it may be a deeply flawed language in some respects, but the fundamentals of the language, prototypical inheritance, true first-class functions, and lexical scoping, are all things that Eich got right. And given first class functions and lexical scope are still things that language designers have trouble getting right (I've got nothing against class-based OO, so I'm not including it here), it's even more remarkable that Eich did it properly in 1997.

Re: Taking PHP Seriously

#593

Earlier quoted context omitted.

> A prototype isn't a class: it's another object. When a method is called, or a variable is looked up on a JS object, JS scans up the prototype chain, all the way to Object.protype. A type in Python is also just another object. When a method is called, or a variable is looked up on an object, Python scans the MRO (effectively the same thing as the prototype chain, except it supports multiple inheritance too) all the…

That looks the same, but conceptually (and actually, code-wise), that's not what JS is doing. Here's what's actually happening, in psudo-python: class Person({name:"bill", addr:"foo"}): #there's no syntax for object literals in Python #such a thing doesn't even make sense: so I'm improvising. pass charlie = Person() charlie.name = "charlie" charlie.addr = "baz" class NewPerson(charlie): #note charlie is an object, no…

> In JS, charlie isn't a class, charlie is an object: you can change all its properties and everything, just like any other object. It's not a class, because there aren't any.

Right; this is actually why I like Python's way a bit better: it makes a more formal distinction between the two. In Python, Charlie is also an object, and you can change all its properties and everything, just like most¹ other objects.

Most of what you try to use to distinguish JS from Python applies just as well to Python. No, it isn't exactly the same, and I think the semantically equivalent code in Python will often contain more information than the JS. E.g., in my conversion of your JS, the class is an instance of `type`, whereas — as you correctly note — it's "just" an object in JS. It's not really though; in most JS that devs will write, the object is a type, but that distinction isn't explicit in the code. It's implicit in the dev's intentions, expressed only in the general sense that the code is being used.

e.g., if I saw, in JS,

  var Person = function(){};
  Person.prototype = {name:"bill", addr:"foo"};
  var charlie = new Person();
while it is true, technically, that `Person` is a function and `Person.prototype` is an object, the semantic meaning being expressed in this manner by the author of this setup is that `Person` is a type, and that charlie is an instance of that type. It's just explicit in Python. (To some degree, JS is aware of this fact too; `charlie instanceof Person` is `true`, after all.)

In a single-inheritance class in Python, during attribute lookup, Python will attempt to look the attribute up on the object's __dict__; if it doesn't exist, then it looks up the parent type (by looking at __class__) and then recurses, trying to look the attribute up there, and proceeding up the "chain".²

In JS, during attribute lookup, JS will attempt to look the attribute up on the object's internal list of attribute (I don't believe this is exposed like __dict__ in Python); if it doesn't exist, then it looks up the parent type (by looking at __proto__) and then recurses, trying to look the attribute up there, and proceeding up the "chain".

What material difference exists here?

¹objects in Python can forbid attributes from being set, or limit the available attributes. I'm not sure to what extend JS lets you do that. e.g., `object` in Python is very restrictive about allowing additional objects.

²I'm explicitly ignoring multiple inheritance here, so I'm vastly simplifying. Python will actually use the MRO for this procedure, but in the case of simple inheritance, that's equivalent to following __class__. I'm also ignoring __slots__ for simplicity.

Re: Taking PHP Seriously

#594
post #484

Earlier quoted context omitted.

> Regardless of their findings I wouldn't recommend anyone learn PHP if starting out. This is bad advice. If you are a new programmer starting out, first of all you should learn a few languages, not just one, but also, why would you not want to learn one of the most popular and prolific languages in the industry you are trying to enter? If you want to work in the web world, not knowing PHP will close lots of potentia…

> If you want to work in the web world, not knowing PHP will close lots of potential doors. Not knowing language X will obviously close doors but by learning language Y instead will open others. Insert whatever language you like. I wouldn't recommend it to someone starting out because it's use is in a limited context. You could do scripting outside of a webserver in PHP but it's not done often. Since there are mature…

The "field" in this conversation is defined as "web development" since we're talking about PHP..

If you were speaking generally about programming then obviously don't learn PHP.

But that's not the context of this thread.

Re: Taking PHP Seriously

#595
post #501

I was kind of surprised to read this and started to think this was just a copy of a previous speech I've heard before. I was right it was: https://www.infoq.com/presentations/php-history but the author is the same person. It is a good speech and I've been developing in php for years, written a blog post ( http://sucky.ninja/leaving-php-is-too-expensive/ ) about it but I do no longer use php for my backends. I've whol…

You can deploy PHP to Azure App Services as easily as you can deploy a ASP.Net app.

I don't think the point is that PHP isn't as easy to deploy. The point is that PHP doesn't have easy deployment as an advantage over other languages.

So if other languages are just as easy to deploy, what does PHP bring to the table?

Re: Taking PHP Seriously

#596
post #353

Earlier quoted context omitted.

But program managers and CTOs and other non-engineers at a company care about scalability, performance, technical debt and quality, right? Let's not pretend that these don't matter once you've gone past the "users actually care about our app" phase, because they do and they affect the bottom line of a company. And IMHO PHP falters in these regards.

Performance? You need to update your act. PHP7 is 3x faster than python and now faster than Java 8 . The only people that can call php slow are masochistic c++ web hacks. https://blog.famzah.net/2016/02/09/cpp-vs-python-vs-perl-vs-...

> now faster than Java 8

Don't trust everything you read on the internet, run the benchmark yourself and see if that result is actually reproducible. (Depends on the heap size.) There is also a "non-std lib" java test case, which doesn't generate as much garbage and, of course, performs much better.

Re: Taking PHP Seriously

#597

Earlier quoted context omitted.

>You require effort in an order of magnitude greater than with PHP in order to achieve the same result.. An order of magnitude? Really? I don't think so. Rust has a library (probably among others) called Horrorshow[1], that exports macros to do html templating. You claim that it is easy in Php to do html templating. But you miss the fact that it provide zero sanity/security checks while doing so. You need to sanitize…

Yes, an order of magnitude, in PHP we're talking about _minutes_ in Rust we're talking about _hours_ or even _days_ for a beginner programmer, ever tried to install Homebrew in a Mac to name an example? It adds at least a few hours to the equation with its dependency on Xcode unless you already know to just install the command line tools. Remember that a beginner programmer doesn't always have a background in Compute…

So, you are saying Php is like LEGO and BASIC for web development. I have got no problem with that. Problem is that people using that in a professional setting and uses it to put stuff online.

>A bakery website written by the kid of a patissier doesn't require that degree of security and performance...

I don't think so. Everything that is put online need to be secure. One day it is just a bakery website. Next day it is accepting credit card numbers. And the kid who did this can get employed as a php developer based on this experience, and might build stuff like that for years, with out a clue in the world that they are using a toy language.

Re: Taking PHP Seriously

#598
post #17

Earlier quoted context omitted.

Elixir and the Phoenix framework work like this, with a process spawned per request.

Ive been hearing nothing but good things about Elixir, I may have to check it out. Any recommended places to start with?

http://elixirforum.com is a good place to check out. There are a few excellent books out there to help you get started with OTP, which makes Elixir beastly, and Phoenix (a web framework) as well. The forums are an excellent place to find deals on books, too.

Re: Taking PHP Seriously

#599

Earlier quoted context omitted.

Underrated comment. To expand on this, static website generators are best for generating documentation and small blogs. It falls apart when you have a large often-changing content. This is where PHP is still king of the web.

> It falls apart when you have a large often-changing content. Today, when one can have workflows via jekyll/git/Continuous deployment, at what frequency of "often-changing" should one move away from static websites to a php based solution?

Take HN as an example. This can't be done as a static site.

Or a simple guestbook or hit counter.

Where the lines may blur is JS front end talking to a BaaS... This may make it possible to glue up impressive sites using just HTML and JS with no custom backend requirement.

Re: Taking PHP Seriously

#600
post #466

Earlier quoted context omitted.

As a counterpoint, Facebook, one of the most secure companies in the world, is also the largest single PHP deployment in the world. C is also a language with a frankly horrific security track record; at least an order of magnitude more so than PHP. But C continues to be used because it is a useful and relatively simple language despite its warts and pitfalls.[1] Security is just as much a business process as it is a…

Or Etsy. I think your comment about C is right, however in many cases mercifully the C code isn't facing the internet :) When it does, it can go very wrong, e.g. OpenSSL. The extra cognitive load doesn't guarantee failure, it just makes it easier to slip up. Even with Python or Rust, you can put insecure code in there (e.g. with Python's subprocess.call(..., shell=True)). Realistically, strict modes and linters are a…

Of course C is facing the internet. The entire Linux networking stack is written in C. Damn near every request on the internet touches that code.
Post reply on HN