Live data from Hacker News

Taking PHP Seriously

slack.engineering

321–330 of 673 posts

Re: Taking PHP Seriously

#321

Earlier quoted context omitted.

It's not. In python, classes are entities like any other object. In JS, classes literally don't exist . Yes, even in ES6. I know there's a class keyword, but it doesn't actually create a class. What the class keyword creates is a constructor function which then initializes new objects with a set of properties, and also sets a prototype, when called with the new keyword. JS objects don't have a superclass, they have a…

> 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, not a class
    pass

  bill = NewPerson()
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.

Re: Taking PHP Seriously

#322

Earlier quoted context omitted.

I cannot agree that OOP in Javascript is anywhere near good. Every library (like Backbone) includes a layer to emulate traditional Java-like classes with private/public fields and inheritance. Because until ES5 there were no syntax for classes, and in ES5 it is just a syntax for adding methods to a prototype and not a real class. And JS is too forgiving, even more forgiving than PHP. In JS you can misspell object fie…

That's because many dislike prototypical inheritance. It's perfectly usable. As for misspelling field names, the same is true for variable names in both languages, and many things in many languages. Here it's more justified, as JS semantics mean that the language can't know your intent in this case: check your spelling.

> As for misspelling field names, the same is true for variable names in both languages, and many things in many languages.

No. This code causes an error in PHP:

    $name = 'John';
    echo $nmea; // error
    class A { public $name; }
    $a = new A;
    echo $a->nmea; // error
This code doesn't raise an error in JS:

    var a = { name: 'John'; };
    doSomething(a.nmea);  // no error
So with JS you learn about errors later and spend more time on debugging.

Re: Taking PHP Seriously

#323
post #16

I work on PHP at my day job (in a public company), before this, I came from Ruby, and .NET before that. I'm convinced the reason so many successful projects use PHP, is not because of any inherent nature of the language. I think it's the people who use it. They just don't care. A successful project needs to be started by someone that cares just enough, but not too much. If you're programming in PHP, you're not runnin…

> It's a garbage language, and you know it. But it allows you to get something up and running, so dang quick.

PHP didn't succeed because of the "language" part. It succeeded because it was limited and focussed to just being a tool to write small web-apps in a short time.

It did one thing and did it better than anything else of the same era (I built CGI apps in C, Perl and Python before discovering PHP).

It was just files, that you ftp-d in and it just worked.

99% of the friction is in writing the first thousand lines of code and PHP meant that nearly all of those lines was business logic, not unescaping POST data or parsing GET parameters.

PHP doesn't remove your ability to think clearly. It is true that it does not provide helpful additions for algorithmic work, but it does not put challenges in your way when writing web-apps. And yet, it does not force you into too much magic about how it works - just enough abstraction for a messy coder.

Re: Taking PHP Seriously

#324
post #16

I work on PHP at my day job (in a public company), before this, I came from Ruby, and .NET before that. I'm convinced the reason so many successful projects use PHP, is not because of any inherent nature of the language. I think it's the people who use it. They just don't care. A successful project needs to be started by someone that cares just enough, but not too much. If you're programming in PHP, you're not runnin…

PHP also has IDEs, tons of tools, tests, and gets deployed with many services and scripts. It's an inconsistent language, it's used by newbies in a very bad manner without even understanding the bare fundamentals of HTTP, but I really wouldn't call it a garbage language. If it were, it would have been dropped ages ago.

But I see what you're getting at... if you need to whip up something quick, don't start experimenting with the "flavor of the day" language or library.

Re: Taking PHP Seriously

#325

Earlier quoted context omitted.

Love this comment. I'm a PHP dev. I do care about my code though. I think you can write niceish code, even with a shitty language.

PHP always reminds me of the Dijkstra quote: "It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."

My first language was Pascal. The concept of combining strings and integers in PHP without any conversion was scary and magical to me at first, but the damn thing worked, as long as you were careful. I still get mad at people who complain about type coercion because they expect their programming language of choice to read their minds and wipe their ass.

And Dijkstra was kidding. As is Rasmus when he says he'll restart Apache every 10 requests. Hyperbole. Learn languages instead of a language and it'll click. It has to.

Re: Taking PHP Seriously

#326

Earlier quoted context omitted.

No. And software engineers in the US, are actively losing their jobs to H-1Bs precisely due to this reason. Because people with this mindset are UNHIREABLE as well as an EXPENSIVE LIABILITY. Say that aloud in an interview or in a 1:1 with your manager and let's see how quickly they make you a job offer or get you promoted. You don't, because you have you keep this to yourself because you know it is wrong and not in t…

> Because people with this mindset are UNHIREABLE as well as an EXPENSIVE LIABILITY. Yes, I agree with you, and I work at places where the label "engineer" reflects this sort of individual responsibility... BUT: > because you know it is wrong and not in the best interest of your employer Look, the way you even phrased that statement is exactly the problem. A US software engineer's primary legal duty is to his employe…

Do your job in the interest of your employer, to the best of your ability, without ripping off your customer.

That's the meaning of professionalism. That's the meaning of living in a society. If you need to say no, then do it. Your job is not to say yes to everything.

What if everyone ripped off everyone all the time? It would be a world of shit.

Ripping off the customer is not in the best interest of the employer, and is being hostile towards society. Think about contributing to society not taking what you can.

Adding customer value is different to adding apparent value with no real substance.

Re: Taking PHP Seriously

#327
post #16

I work on PHP at my day job (in a public company), before this, I came from Ruby, and .NET before that. I'm convinced the reason so many successful projects use PHP, is not because of any inherent nature of the language. I think it's the people who use it. They just don't care. A successful project needs to be started by someone that cares just enough, but not too much. If you're programming in PHP, you're not runnin…

PHP isn't quick. It isn't faster than other languages. It's just a tool, and if you know how to use it well, it will be faster for you . If you want fast, build a static site. If you're iterating on your builds and doing something non-trivial, pick your tools carefully but don't be afraid to try new things.

>PHP isn't quick.

As of PHP7... it actually is quicker than other languages in it's domain.

Re: Taking PHP Seriously

#328
The shared nothing request model leads to laziness. And once you get to any kind of scale you'll want to run PHP in something like php-fpm with lighttpd or nginx, which actually does aggressive caching. It's painfully slow to re-evaluate for every single request. This introduces subtle problems because your code was probably shit to start with.

Of course, this is not a post about how good or bad PHP is/was. It's just a matter of personal preference at the end of the day. Your favorite language is the one you feel you're the most productive in and says a lot more about you and your experience/background than the language itself.

Re: Taking PHP Seriously

#329

Earlier quoted context omitted.

That's because many dislike prototypical inheritance. It's perfectly usable. As for misspelling field names, the same is true for variable names in both languages, and many things in many languages. Here it's more justified, as JS semantics mean that the language can't know your intent in this case: check your spelling.

> As for misspelling field names, the same is true for variable names in both languages, and many things in many languages. No. This code causes an error in PHP: $name = 'John'; echo $nmea; // error class A { public $name; } $a = new A; echo $a->nmea; // error This code doesn't raise an error in JS: var a = { name: 'John'; }; doSomething(a.nmea); // no error So with JS you learn about errors later and spend more time…

Actually it throws an E_NOTICE. Something a fair amount of projects require you to turn off. You know what else throws an E_NOTICE?

    $a = notice_there_are_no_quotes;
    echo $a; // $a gets assigned the string 'notice_there_are_not_quotes'
This is super fun when you attempt to use a constant and misspell it.

    $b = MY_CONSTANTT;
    echo $b; // $b is now the string 'MY_CONSTANTT' instead of whatever the correct MY_CONSTANT was set to.
Which is why in both PHP and JavaScript if you really cared about what you were doing, both of those would be methods that throw errors if misspelled

    let a = new A();
    a.setName('John');
    doSomething(a.getNmea()); // Error

    $a = new A();
    $a->setName('John');
    doSomething($a->getNmea()); // Also error

Re: Taking PHP Seriously

#330

Earlier quoted context omitted.

"Node isn't very good at HTTP" is just blatantly false. Most languages don't "have to do HTTP" and those that do often do a pretty terrible job. Somehow Node not only does it, but does it well, where a bare Node process behind some load balancers is often enough to get the job done. PHP on the other hand needs all sorts of hand-holding to work properly.

Node is stateful and not threaded, but yes you're right that it serves http out of the box. Http was a module in the early days but I see now it's core API and has been for a while. My mistake.

Node isn't a pure functional language, and neither is PHP. I'm not sure what you mean by "stateful" otherwise.

JavaScript does have threading facilities like WebWorkers, but they're often largely overlooked since the code complexity that comes with it isn't worth it and the multi-process model generally works fine. A single Node process can do a lot of work because of the aggressively asynchronous approach to processing it takes.

Node + Express is actually a pretty slick package.

Post reply on HN