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

PHP – The Right Way

phptherightway.com

Post reply on HN
Print view View original

71–80 of 349 posts

Re: PHP – The Right Way

#71

Post by JodieBenitez »

deniska wrote: post #45
JodieBenitez wrote: post #25

Earlier quoted context omitted.

"new hipster" programming languages: Python 1.0: January 1994 PHP 1.0: june 1995 Ruby 1.0: December 1996

Sure, but if we're talking about these languages being "socially acceptable" for writing websites, they arrived a bit later to the party than PHP. Granted, it still happened about a decade and a half ago, so I hoped the sarcasm using the word "new" would come through.

> I hoped the sarcasm using the word "new" would come through.

It did ;-) . But I frequently meet devs (young and old) that believe Python, Ruby and others are "new" languages. So I think it's worth mentioning they are not in any way.

Of course age does not equate maturity. Neither social acceptance.

Re: PHP – The Right Way

#72

Post by StreamBright »

that_guy_iain wrote: post #52
rbanffy wrote: post #34

I totally expected it to be a troll site. It's actually sensible advice. But, really, I suggest using other tools. We have nicer tools now.

> But, really, I suggest using other tools. We have nicer tools now. Debatable really. Within the web development space the options are rather limited in my opinion. Options: * Spring based apps - Downside JVM is a Resource hog * Python, Ruby, etc - The web frameworks are in my opinion not as full featured. Same with CMS systems. Also requires more resources. Also have limited OO features. * Go, Rust, etc - Really go…

We use Asp.NET and it is a giant surprise how good it is. We are unix ppl, Linux & MacOS so not a MS shop at all. We deploy to on-prem and AWS so no Azure.

Re: PHP – The Right Way

#73

Post by gocartStatue »

BafS wrote: post #16
sdze wrote: post #13

Earlier quoted context omitted.

Artisans? First time I hear that. I certainly use PHP and never called myself an Artisan.

It comes from Laravel ( https://laravel.com/); "The PHP Framework for Web Artisans". The command line entry point is also called "./artisan".

Which by the way is heavily mocked by PHP developers actually using OOP, dependency inversion, hexagonal architecture etc. Which is not the "artisanal" way of development it seems :)

Re: PHP – The Right Way

#74

Post by CR007 »

TekMol wrote: post #61
CR007 wrote: post #49

Earlier quoted context omitted.

Did you actually get these issues in a real use case? I've been developing PHP software for +15 years and I never had this namespace dilema.

But you suffer the indirections caused by the fat stack that is needed to deal with the missing import system. In Python, "import" actually imports the code. In PHP, the "use" statement you see everywhere does not. It only works because the code has already "magically" been imported. Usually by composer. Thats why there are tens of thousands of hits for "clear composer cache" on Google. To just point out one issue wi…

The fact that composer comes with an autoloader doesn't means that you have to autoload everything.

You can manual include, define your own extra auto loader and use interfaces to quick swap for custom implementations.

Like I said, +15 years. Composer is 9 years old. How do you think we handle this in our own Jurassic times?

Re: PHP – The Right Way

#75

Post by sshine »

sdze wrote: post #15
thriftwy wrote: post #6

Earlier quoted context omitted.

In the mid-00s the main selling point of PHP were shared hostings with mod_php which was a cheap way to host your own web site and database. Now with the cloud that advantage is utterly gone.

PHP still has a vibrant ecosystem. 1) cost 2) simplicity 3) scalability With the advent of Chinese frameworks that solve C1000K problems like swoole, workerman and so on it even found its place as high performance interactive backend server.

I spent the better part of 2021 porting a PHP app to Kubernetes. If there’s one thing PHP is not, it is performant.

Re: PHP – The Right Way

#76

Post by captn3m0 »

TekMol wrote: post #36
ainiriand wrote: post #32

Earlier quoted context omitted.

You can hope all you want but you won't be able to submit any duplicated namespace to Packagist.

That is another consequence I don't like about the quirky namespace approach. It collects more and more problems like a ball of dust that gets bigger and bigger. The consequence you mention is that one depends more and more on tooling and services.

The autoloader in composer offers several alternatives, and while all of them are namespaced per convention - nothing stops a project from deciding to write their own - something super easy in PHP but impossibly hard in other languages.

I find PHP packaging and dependency management to be painless compared to both Python/Ruby.

Re: PHP – The Right Way

#77

Post by akie »

psychoslave wrote: post #64

Actually, that make me remember statements of Linus Torvalds on Git at Google Tech Talk Conference: But I did end up using CVS for seven years at a commercial company and I hated it with a passion. When I say I hate CVS with a passion, I have to also say that if there are any SVN users in Subversion, users in the audience, you might want to leave because my hatred of CVS has meant that I see Subversion as being the m…

No post body was provided.

Re: PHP – The Right Way

#78

Post by jwdunne »

rbanffy wrote: post #40
ainiriand wrote: post #32

Earlier quoted context omitted.

You can hope all you want but you won't be able to submit any duplicated namespace to Packagist.

Java solved this by using domain names as unique identifiers. I can use com.banffy and be sure only a complete a*hole would make a package in this space.

This is roughly PHP’s approach. In this case, Illuminate is the vendor prefix and Mail is the package name. This often but not always corresponds to the rules around the composer package name, which would be illuminate/mail in this case.

This is similar to NPM’s organisation prefix (@foo/bar).

But yeah, I’m not defending the hacky way namespaces are resolved through autoloading. I do prefer actual language support for a module system (but Ruby suffers from this problem too).

Re: PHP – The Right Way

#79

Post by sdevonoes »

rbanffy wrote: post #67
lpcvoid wrote: post #60

Earlier quoted context omitted.

I, for one, would chose PHP8 over Javascript all day, every day. And there seem to be millions like me.

Well... I wouldn't recommend JavaScript. TypeScript is much nicer and removes a lot of the JS pitfalls.

And pulling ~67 dev dependencies just to be able to transpile TS to JS? No thanks.

https://www.npmjs.com/package/typescript

Re: PHP – The Right Way

#80

Post by onion2k »

tored wrote: post #48
rbanffy wrote: post #34

I totally expected it to be a troll site. It's actually sensible advice. But, really, I suggest using other tools. We have nicer tools now.

What tools? What server language today except PHP (and its forks) is actually designed for the web and works as the web was intended?

What server language today except PHP (and its forks) is actually designed for the web and works as the web was intended?

The implication of the question is that there's something designed into PHP that makes it better for working with web things. Why does the language need to be designed to work with the web? That part of any language can be filled out with a framework quite easily, and arguably that means it's much easier to change how the language is used. That seems to be the case with every major PHP application anyway - most use Laravel or Cake or Symphony or something. Just as most Ruby web projects use Rails, and most backend JS projects use Express, and Rust web projects use Poem, and so on.

I don't think there's a good reason to design a language specifically for web projects. If that's how PHP works these days (I haven't used PHP in a decade or so), I'd suggest that might be a bad thing. It's very rigid, and if the language gets anything wrong that compromises the design of every project that uses it. Languages should provide simple primitives that frameworks and libraries build on.

Post reply on HN