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

Taking PHP Seriously

slack.engineering

Post reply on HN
Print view View original

531–540 of 673 posts

Re: Taking PHP Seriously

#531

Post by oxyclean »

swalsh wrote: 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…

I would never have agreed with you before, but I just came from a place where the fear of using something that was not sexy just paralyzed most of the developers at the company. They spent more time talking about new tech than implementing it. I've sworn off PHP, but at one point there I would almost have preferred they suggest we use it, if only to get something shipped.

Now I don't fret as much about unsexy tech. I do still advocate for new things when they make the team more productive, but I hope I never have to work at a place again where the latest and greatest stuff is used and people get nothing done.

Re: Taking PHP Seriously

#532

Post by NHern031 »

raarts wrote: post #488
NMDaniel wrote: post #272

Earlier quoted context omitted.

There are plenty of great server-side languages and environments. C#,Java,Scala,Python,Ruby,Haskell. If this was about JavaScript and Front-End I might've agreed with you (there are transpilers but interoperability with JS modules can be tricky), however in the realm of servers there's so much freedom.. so why choose PHP out of them all?

C#: windows or mono-on-linux Java: keyboard wear Scala: not enough programmers Python: not bad Ruby: too slow Haskell: math grad required

The .NET CORE is now open source and cross platform. Cross platform compatibility with the exact same source code, and the killer features/speed of C# makes its my personal choice for a server-side language. I would like to add that C# devs are not cheap and also seem to be slightly more limited in today's market compared to PHP devs.

Re: Taking PHP Seriously

#533

Post by Twirrim »

dpcx wrote: post #255
toast0 wrote: post #157

Earlier quoted context omitted.

> Code paths, auto-loaders, database connections, config files, etc. All that has to happen over and over for each request. Do you most of those need to happen at all, ever? In my mind, auto-loader is a sign that nobody knows what's being loaded (if they did, they would just require it). Requires should be full pathed (because have you seen what happens when you search the include path). Mysql_pconnect has been doing…

IMHO, developer time is more expensive than CPU time; I don't want or need to have to write out all of those requires. That's the job of the autoloader. And if I'm writing my code remotely well enough, each section only uses the things that it needs. Granted, there may be some things that each request get that they don't need with the autoloader. But I can optimize later. "Make it work, make it right, make it fast"

> IMHO, developer time is more expensive than CPU time; I don't want or need to have to write out all of those requires.

Every wasted millisecond on the server side matters. It impacts scalability, customer experience (and revenue) etc. You should take every easy win you can get there.

Not doing full includes is just ridiculously lazy. It doesn't take that long to write them out, and your IDE can help you out there. I bet you spend more time on social media during office hours than you'd ever save from not having to type out those import statements.

Re: Taking PHP Seriously

#534

Post by qwertyuiop924 »

OOPMan wrote: post #467
qwertyuiop924 wrote: post #321

Earlier quoted context omitted.

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…

I notice you conveniently ignored the meta-programming capabilities of Python which would allow your "nonsensical" improvisation to work just fine. Brush up on your Python skills before talking rubbish.

Classless object literals actually don't make sense in the Python model. It seems like you're the one who needs to brush up.

In any case you're not actually providing any links or facts, so unless I dig through long articles on metaclasses in python, I can't verify anything you say. Please prove your point, or at least provide I link so I can verify.

Re: Taking PHP Seriously

#535

Post by [deleted] »

OOPMan wrote: post #467
qwertyuiop924 wrote: post #321

Earlier quoted context omitted.

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…

I notice you conveniently ignored the meta-programming capabilities of Python which would allow your "nonsensical" improvisation to work just fine. Brush up on your Python skills before talking rubbish.

[deleted]

Re: Taking PHP Seriously

#536

Post by forgottenpass »

mikey_p wrote: post #72
Klathmon wrote: post #11

The article points out that arguably the best part of PHP is the "shared nothing lifecycle". That each request starts new, and the process dies at the end of the request. It's by far my favorite part, and I completely agree that it makes "reasoning about" (boy do I hate that phrase...) your program much easier. Why are there no other "competitors" in this space? Why do most other languages go with the alternative rou…

The downside is literally exactly the same as the upside: you have to bootstrap from literally nothing for every single request. Think about how ActiveRecord in Rails reads from the DB schema to generate it's magic methods, etc. This is usually done on startup or at least cached in memory once it's loaded. This is something that you have to manage more carefully with a PHP app since you can't have anything initialize…

The downside is literally exactly the same as the upside: you have to bootstrap from literally nothing for every single request.

Well, it depends on how it's implemented, and how pedantic someone gets about what "shared nothing" means.

There is a long history of unix daemons that initialize, listen(), and then fork off a child process whenever a client connects. The child does all the work and the parent goes back to listening. You can do the "up front" work once and then each child can only modify their copy of the data, preventing it from interfering with the next request.

Re: Taking PHP Seriously

#537

Post by astrodust »

fiedzia wrote: post #403
astrodust wrote: post #330

Earlier quoted context omitted.

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

WebWorkers have nothing to do with threading. They will not let you share memory, and this means that you waste time on seriazlizing/deserializing anything you pass to them, so from optimization point of view, they are more like processes. This makes js completely unsuitable for things that are data-heavy and cpu-bound (just cpu-bound may work, but it still not the best choice).

They do have a lot to do with concurrency, which is often what threads are used for. They do have limitations to fit in with the JavaScript model.

JavaScript is generally a lot better at compute intensive tasks than contemporaries like Ruby, Python, PHP and Perl due to the incredible performance of the V8 engine and others like it. The language is ugly, but it's more easily optimized by the JIT compiler.

If you're arguing JavaScript isn't as good as C++ or C, sure, it isn't, but few languages are, and none of those are frequently used for general-purpose web development.

Re: Taking PHP Seriously

#538

Post by astrodust »

NormlOverrated wrote: post #327
astrodust wrote: post #164

Earlier quoted context omitted.

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.

Compared to Ruby, sure, but pretty much everything is at this point. Compared to Node JavaScript? Not even close.

They've made some impressive gains in PHP7 that others should take note of. Ruby's particularly out of shape here compared to the competition, though Python isn't exactly a speed demon either.

Re: Taking PHP Seriously

#539

Post by astrodust »

regularfry wrote: post #423
astrodust wrote: post #306

Earlier quoted context omitted.

You really can't beat the speed of a static page. For anything with a server-side component, PHP might be fast if you know a lot about how to get PHP up and running properly. Node, as a counter-example, runs on Windows and POSIX systems indifferently, and with very little effort can be a self-hosted web server for development that can be deployed to production almost effortlessly. If you have a favorite hosting provi…

I think you're overestimating how much effort it is to get a PHP dev or deploy environment up and running. This isn't preference and familiarity, it's 20 years more knocking the corners off to lower the barrier to entry.

There's zero work involved in getting a static page up and running. There's minimal effort in getting Node up and running, and I'd put it forward as the new "path of least resistance" especially because of the heroic work done to make Node run properly on Windows.

Getting WAMP or whatever configured and installed, or loading the PHP module into Apache or Nginx and getting that working is a giant pain in the ass compared to either of those two things, even if you've done it a dozen times before.

Re: Taking PHP Seriously

#540

Post by dmux »

BaconJuice wrote: post #521
EJTH wrote: post #402

Earlier quoted context omitted.

The way you write code I wouldn't trust you with any language really. You give 6 lines of code and it has display of all the worst practices that I haven't seen since I read a 13year olds tutorial on the language back in 2003.

Hi, can you list all the worst practices you see in this code? Just curious of the full list

No input validation for one, possibility for SQL injection is another.
Post reply on HN