Live data from Hacker News

PHP – The Right Way

phptherightway.com

231–240 of 349 posts

Re: PHP – The Right Way

#231
I want to like PHP, but it seems that there are so many better/modern alternatives out there, IMHO Go and Rust are the most notable new ones, Go is almost (if not yet) ahead of PHP in terms of community and resources (learning and packages), while Rust still needs a few years to establish (the async issue and few others) and the maturity of the ecosystem, there are no killer solution yet (maybe there will never be).

I tried PHP last year (or should I say Laravel) and didn't found any good, the type system is bad for a project like Laravel, you have too many different files where you declare things and the type system doesn't now, so you end up without autocompletions (and warnings or errors from the php interpreter) you only catch those at runtime (I'm too used now to get the errors before run a project, or at least get a hind from the editor/IDE).

Re: PHP – The Right Way

#232

Earlier quoted context omitted.

There is one aspect where it wins hands down that trumps almost every other concern that you might have: availability of developers. This is a hard problem to solve.

Raw number of developers doesn't matter at all. The ratio of offers to developers out there determines how easy the hiring actually is. I've tried to hire some quality PHP developers and it's as hard as Ruby/Python if not harder. First thing is, that you always get all the Wordpress people, who fixed one plugin and claim to have 10 years of PHP experience. Then you have to filter out all the 10 YoE who actually have…

It does if the number is '0' vs 'some'. It usually depends on how and where you do your hiring. For those that only want to hire local developers it is very well possible that there are no local Rubyists, it is also possible that it is the other way around.

Typically there are a lot more proficient PHP programmers than Ruby programmers around here, but if a company were open to remote workers the situation would right away change considerably.

There is also the price factor to take into account.

All in all, more often than not developer availability works itself into these choices.

Re: PHP – The Right Way

#233
post #186

Earlier quoted context omitted.

The fair comparison: PHP/Laravel to Ruby/Rails... How is PHP/Laravel better? I'm of the opinion it loses hard in every aspect.

There is one aspect where it wins hands down that trumps almost every other concern that you might have: availability of developers. This is a hard problem to solve.

A good dev with only PHP skills becomes a better dev when he/she has other experiences. Ruby or Kotlin would not be off by too much. In my experience they productive in days and are up to speed in a few weeks.

It's a small investment.

Having your code in PHP is a liability considering great free alternatives exist. If you can do it in Kotlin and have your code in a well types language, that is a bit win down the line.

Re: PHP – The Right Way

#234

I want to like PHP, but it seems that there are so many better/modern alternatives out there, IMHO Go and Rust are the most notable new ones, Go is almost (if not yet) ahead of PHP in terms of community and resources (learning and packages), while Rust still needs a few years to establish (the async issue and few others) and the maturity of the ecosystem, there are no killer solution yet (maybe there will never be).…

You didn't try PHP, you tried Laravel.

Re: PHP – The Right Way

#235
post #82

Earlier quoted context omitted.

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

Mocked as in made fun of? Personally (in 7 years as a PHP dev) I've not found this. There was one company I interviewed at where the lead engineer thought facades were dumb, but then couldn't explain why he needed to rebuild the entire backend in Node. Perspective.

Yes, made fun of. Philosophy of Laravel crowd seems to be similar to "the rails way", which means a lot of framework-specific solutions, disregard for TDD etc.

Well, static service locators disguised as "facades" are a bad design. Rebuilding entire backend in Node for that reason alone is dumb. Laravel features a PSR-compliant DI container and supports dependency injection with autowiring, you can very well write a nice, decoupled, SOLID code using Laravel. But it's rather not the thing people have in mind when picking it over Symfony or Laminas.

Re: PHP – The Right Way

#236

Earlier quoted context omitted.

Have you ever used Elm or Rust? Maybe you expectation of how decent error messages should look like is just lower. The problem is that the type system in TS can get crazy complex and has many uncommon features like structural typing. You need to have a really good mental model of how TS works to be able to make sense of what TS tries to tell you.

> You need to have a really good mental model of how TS works to be able to make sense of what TS tries to tell you. Won't this sentiment hold true for Rust as well? You need to have a good mental model of how Rust works, with all its borrowings and lifetimes, to understand what its errors are trying to tell you, and especially how to fix the problem?

Actually no. Rust will teach you.

The difference is that errors do a great job and telling you what went wrong and how you can fix it. You just fix one error after another and the borrow checker will guide you to the correct solution.

For example you get an error like:

  error[E0433]: failed to resolve: use of undeclared type `Environment`
   --> src/main.rs:9:19
    |
    |     let mut env = Environment::new();
    |                   ^^^^^^^^^^^ not found in this scope
    |
  help: consider importing this struct
  |
  | use foobar::test::Environment;
  |
You could fix this error without knowing Rust.

You obviously need to know the basics of systems programming to effectively program in Rust and some type errors get tricky, still it is a more interactive experience and you can just jump in while in TS just jumping in does not really work and the level of type safety relies on your skills as a developer.

Re: PHP – The Right Way

#237
post #233

Earlier quoted context omitted.

There is one aspect where it wins hands down that trumps almost every other concern that you might have: availability of developers. This is a hard problem to solve.

A good dev with only PHP skills becomes a better dev when he/she has other experiences. Ruby or Kotlin would not be off by too much. In my experience they productive in days and are up to speed in a few weeks. It's a small investment. Having your code in PHP is a liability considering great free alternatives exist. If you can do it in Kotlin and have your code in a well types language, that is a bit win down the line…

I'm not religious about languages, I probably used to be, but I grew up and grew out of it.

Having your code in PHP is no more a liability than having it in any other framework/language combo if you don't know what you are doing, and people that don't know what they are doing abound in any eco system.

PHP is just a tool, Ruby is just a tool. If you haven't spent an equal time in both you are probably not in a very good position to judge either. I've done a lot of PHP work, I've done a lot of Ruby programming and I dislike either with roughly equal passion to the point that if I never have to code up another website back end my life will be measurably better. The same goes for Python, Java, .Net, Go and whatever else we use to cobble together websites.

All of these are broken and leaky at multiple levels and the 'perfect' solution to build websites doesn't exist, in fact I don't think there is even a half decent one. This is a direct consequence of trying to shoehorn application development into a platform that was never meant to be used that way, but that's another discussion entirely. So you pick whatever is least offensive to you and your team, and probably you'll pick that which you are most familiar with or that seems to come closest to a fit for the kind of problem you are trying to solve.

Re: PHP – The Right Way

#238

Earlier quoted context omitted.

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

> The language itself, the downsides are very limited and the main one that remains valid is inconsistency of function parameters. Usually one would have an IDE's auto completion to take care about function parameters, and in any case PHP8 has named parameters now to reduce whatever confusion (especially when optional parameters come into play) remains.

Sure, auto-completion makes the code easier to write. But you can't make it easier to read.

Re: PHP – The Right Way

#239

I want to like PHP, but it seems that there are so many better/modern alternatives out there, IMHO Go and Rust are the most notable new ones, Go is almost (if not yet) ahead of PHP in terms of community and resources (learning and packages), while Rust still needs a few years to establish (the async issue and few others) and the maturity of the ecosystem, there are no killer solution yet (maybe there will never be).…

Not sure about your experience with Laravel, but I don’t see how the type system is bad for it. It works surprisingly well for me. With a bit of tooling I get even autocompletions for database fields when using Eloquent. PhpStorm with the (paid) Laravel plug-in are pretty awesome and give me more information during file-editing than for example Xcode.

Laravel has also a pretty active and productive community and so many things just work out of the box, I’m not sure if Go or Rust has anything comparable.

I have to mention: I didn’t touch Go for over a year now and never used Rust. I felt that Go is pretty easy to learn in its basics but quickly throwing things together for a prototype with DB access, I would go for PHP at any time.

Re: PHP – The Right Way

#240

PHP is a language with various features that might make it attractive to certain people: • CGI-like execution model when used for the web, making resource leaks very difficult and encouraging scalable design • not only integers and floats, but also strings, lists and dictionaries as mutable value types (copy-on-write) — this is a big difference from JavaScript and Python • unusually for a dynamic “scripting” language…

* duct-tape style of arrays that Just Work(tm) as arrays, hash maps, etc. without having to use any boilerplate code. It's the main reason why I still prefer PHP for quick&dirty scripting and data processing.

I love PHP "arrays" but there is one tiny gotcha that becomes more important as we do type-safety stuff more and more.

`$a['1'] = 'string';` becomes `$a[1] = 'string';`. This appears to be the case for any fully-fledged decimal number where `(string)(int)$key === $key`

So if you are expecting `array_keys` to return all strings, you might get surprised

Post reply on HN