Hacker News Reader

Comment by fredsted | Hacker News Reader

I wonder if most developers that trash on PHP for trivial issues like seen in this thread haven't been using it for many years, or had a bad experience (e.g. maintaining a legacy app).

Some developers live in a kind of technical vacuum where, I guess they assume, the technical features of their programming language are what makes the difference in the value of the business they're building.

In reality, the difference is in how easy it is to hire developers, the package library, overall ecosystem and developer experience, or: how can I make a great product.

View on HN

I'm a PHP "hater", so take this for what it's worth.

You are very close to implying that the language doesn't matter if you can hire developers and there are a lot of good packages in the ecosystem.

Having worked on several PHP projects (Most being version 7.0+ and zero of them being older than 5.3), the languages is STILL full of gotchas, and it's a huge drag on productivity. I assert that this DOES matter. Even basic stuff like trying to use the default "array" as a dictionary has absolutely ridiculous issues like if you try to use a string as a key, but it is a string of digits. It will automagically convert your string to an int and totally F-up your dictionary.

I've actually been bitten by that one. And it showed up in production, because I didn't know or care what the string keys might be. Who the hell would've guessed that behavior after working with non-broken languages before?

Inb4 "That just means you're dumb. Just use SPL. You can write bad code in any language."

I've used Symfony. It's good. I haven't used Laravel. I assume it's also good. I still don't know why you'd choose to start a project in PHP today when there are great libraries in many other languages that are not as broken as PHP.

Honestly, PHP 7+ is not horrible, but it's also not better than anything else... In fact, the very best PHP code you can write today looks basically the same as the best Java code you could've written a decade ago.

What are "string keys"?

Associative array or hashmap. Arrays indexed by strings instead of numbers.

Ohhhh I've never heard them called string keys before. Thanks.

PHP arrays can be indexed by ints or strings (at the same time).

For a huge, huge potion of all work done by web developers day to day around the globe the language doesn't matter if the framework is productive and secure by default.

Most of it won't survive a handful of years at best and most companies won't ever benefit from the attitude of some developers that ever developer on ever task should be writing FAANG level code.

What 3nds yo happening it matter what you do is the next agency / person comes along and claims its not fit for purpose any more and redoes it 'better' and the cycle continues of low value

> if you try to use a string as a key, but it is a string of digits. It will automagically(sic) convert your string to an int and totally F-up your dictionary

I've been a PHP programmer for over 15 years and I cannot think of a single time this has been an actual problem. It sounds like you were embarrassed by a bug in your code and have just decided to blame it on the tools.

I've run into that numeric reindexing confusion. PHP arrays in general are so feature rich it's also easy to overuse them.

The proliferation of Collection classes may be one side-effect of how poweful-yet-awkward they are.

Is "powerful" really even the right description? I can't even do a map + filter without looping through the array twice. Ew. I guess I'll just stick with the primitive foreach loop (which leaves a dangling allocated object after you use it... sigh).

My guess is that the numeric indexing thing happens a lot but it's definitely rare for it to cause a visible problem and even rarer to be identified as the cause since it is unexpected.

I've been bitten by it and also stuff like 800=="8E2".

I've never been able to make an adequate defense of PHP, yet also have never seen another language match its success rate of getting useful software into the hands of users. I have wondered whether something about PHP, or something that it lacks, makes PHP projects easier to estimate.

Ease of deployment? Batteries included standard library? Pragmatic community? Surprisingly adequate performance? It never seems like enough to overcome the obvious deficits. I can neither ignore my own experience nor convince anyone that it's actually great.

I'm in a similar boat. I've decided that whatever it is that makes PHP successful must be exactly the same thing that has made JavaScript successful.

It's going to sound extremely condescending, but here it is, anyway: I believe that the majority of people who defend PHP (and JavaScript) are people who have ever only written code in Java (especially <=1.6), JavaScript, and PHP. Maybe C for fun or in college. In light of those immensely popular languages, I could see why someone might not think that any of the deficiencies are deal-breakers.

Maybe, in my case since I am currently in the non-PHP phase of my alternating PHP/non-PHP job history. PHP has been less than 50% of what I've done (the rest being far more on-trend, if you will) though disproportionately represented among successful and profitable projects.

The only-ever-PHP coders I have known tend to be fairly polarized between fear of the unknown and the "grass is greener" attitude.

The ease of estimation thing was an aside, but I'm getting more convinced. With PHP there is only one way to do any feature: look up the library function, type it, refresh the page, and slowly accrete your functionality. With other languages there's some hope of a free lunch and it engages our tendency to optimism.

With other languages there's some hope of a free lunch and it engages our tendency to optimism.

Asking as someone who's mostly only written PHP (and some javascript, more recently): can you expand on this? What kind of "hope of a free lunch" is there with other languages?

I think there are a few, and maybe I am the only one who has ever been foolish enough to think these things or incompetent enough not to achieve them.

The first is the promise of DSLs and meta programming, where you can tune the syntax of the language to more naturally express your problem domain. When this works it's beautiful, but sometimes it is a distraction and makes the code difficult to debug.

The second, which is conceptually very different but I find it can play out similarly, are rich type systems where you can hopefully build up your application as a series of well defined type relations and transformations. Again, when this works you get really robust, reliable, and easy to modify software but there are often cross cutting concerns or business practices that break the model.

Edit: when I talk about a free lunch or a silver bullet, I am often thinking about the writing of Fred Brooks.

As someone who's worked heavily in C++/Java and tends toward functional programming approaches I enjoy PHP. There are some features in the language you should avoid, variable-variables being one of the ones that makes logic very difficult to decipher - but C, C++ and Java all have those - and Javascript has the wonderful combination of substr & substring. The useful portions of PHP are extremely powerful, having access to magic functions, a much more advanced concept of a local symbol table and a surprisingly good approach to inheritance & composition all end up bringing down code maintenance when well applied to provide clearly intentioned logic.

Going a bit off-topic, but I can't imagine doing "functional" programming in PHP or Java. C++ has const and top-level functions (PHP kind of does, but the autoloader...). It has (real) generics. It has move semantics, which is great for functional pipelines.

I do functional programming in C# and used to do it in Java at university. C# makes it marginally more pleasant but in general it’s pretty feasible, people will just look at you funny.

Just to tease it out more. What do you mean by functional? I assume that you design your classes to be immutable (only getters with defensive copies when needed). Do you also keep most business logic as pure, static methods on non-data-holding classes?

That's about as far as you can go with Java, I guess, but honestly, now that I type that out, I guess that does get you pretty far...

Yes, classes are just POCOs (sometimes with some sealed subclasses, to hack sum types) and business logic is static functions in separate classes. Like I said, C# makes this somewhat easier, with things like readonly fields, get-only auto-properties, System.Collections.Immutable, readonly structs, pattern matching, etc. With Java you have to take more care to encapsulate things properly, though I’m excited for records coming into the language.

The most salient problem is the fact that the languages do not distinguish between references and values (aka “mutability by default”) which means that the compiler will not maintain those invariants for you unless you annotate things specifically, and the authors of the libraries you use do the same.

My overall preference is for F#, which is ironically a better object oriented language than C#, by virtue of using ML-like syntax instead of C-like. Nonetheless, C# is a passable functional programming language these days, and the language designers keep adding more functional-inspired features with every release.

I have done PHP for 15+ years. I also use Javascript.

However, I also use C/C++(Mostly low level embedded), C#, and Golang regularly.

If I was given the choice of what language(excluding C/C++) to launch a new web site I would still choose PHP with `strict_types=1` enabled.

Yes, that did sound condescending. I'm both a defender and detractor of JavaScript. I'm mostly a detractor of PHP, but could possibly defend it once in a while if I see misinformation.

Peter Norvig at some point came to the realization that the deficiencies of Python relative to Lisp were not deal-breakers, and I don't think that stemmed from his limited experience.

Perhaps it was condescending, but it was, first of all, not intended to be malicious. I have had the luxury of having used a lot of programming languages for various projects. The first N years of my career, I used mostly C++ and Python. I didn't like Python much and was pretty convinced that C++ was the pinnacle of programming languages.

Since then I've done (real, professional, for-profit) projects in PHP, Go, Java, Kotlin, Swift, Rust, JavaScript, Elixir, and Clojure.

So when I work on PHP and Java I can feel what they're missing. It's simply the luxury of having experienced working in (what I consider to be) better languages. Clojure and Elixir were not my cup of tea, but I still find them to be better quality languages than JavaScript.

I have met many developers in my life. Some with quite a lot of experience. The VAST majority of them have only ever worked in a handful of very similar languages. Mostly the ones I listed originally (I forgot C# in the list, but that's more-or-less Java++). If I'd only ever used PHP and Java I would literally not know what a good type system looks like. It's ignorance, but not stupidity.

And I'm talking about people I have much respect for. People who I acknowledge are smarter than me. That doesn't mean I don't know anything they don't, though. And if they've only used PHP and Java, then I know some things they might not. That's all.

EDIT: Also, I'm not sure what Peter Norvig has to do with it. I bet he doesn't like PHP, either.

> Also, I'm not sure what Peter Norvig has to do with it. I bet he doesn't like PHP, either.

Your comment wasn't about people who like PHP. Your comment was about people who defend JS or PHP to the minimal extent of saying their deficiencies are not deal-breakers.

There are people with broad experience who are willing to accept deficiencies of a particular language if the context is right.

(I don't actually know what the right context would be for PHP; I'm more stating a general principle.)

I suppose you're right. I did not mean people who shrug and say "Yeah, PHP sucks, but I'll defend its use here for X reason."

I was more, in my head, describing people who say "Well, all languages have issues." or "You can write good/bad code in any language." or whatever other bottom-of-the-barrel defenses I often hear and read.

It's a real-life problem. I just recently stepped in it while working on some software that interfaces with imap. A couple of folders were named "2018" and "2019" and common array*() operations kept blowing up with those keys.

I ended up building out a whole new array class to work around it. The notes at the top of my class file pretty well describe the problem: https://github.com/robsheldon/asinius-core/blob/master/src/A...

There are native-php workarounds and if you're very very careful you can probably maybe encounter this and code around it without triggering any of the strange behaviors, but it's a minefield.

I'm not new to PHP, either. I think by chance people just usually don't encounter the circumstances for this particular bad behavior, but when it happens, it's really bad. Array keys shouldn't be getting implicitly typecasted.

I agree that the issue mentioned above isn't that bad - as a long time PHP developer (and PHP admirer) one gotcha that still really annoys me is persistence of key refs outside of foreach loops and I present this eval[1] as a wonderful example of why you should really prefer array_map for mutating array values or be very pedantic about unsetting variables when you leave a foreach using ref loop.

1. https://3v4l.org/99pMn

Except that if you do anything other than mapping, you start taking a performance hit. If you want to use array_map with array_filter, you're now iterating your array twice. Also, if you ever use array_filter, you almost certainly need to wrap it in array_values, so now you're looping N times.

It's no wonder people still lean on the broken foreach. I always use unset() after foreach. It makes me die inside a little.

You remember every bug you've written in 15 years?

I'm not that talented. I write bugs all the time. Most of the time, tests save me.

You can size me up as just childishly trying to divert blame when I made a mistake, but you're missing out by doing so.

I've done plenty of PHP programming (including modern) in the past. I'm excited about recent developments.

Not sure about the productivity claim. I once wrote from scratch (frameworks excluded) backend and frontend (version 1) of a multi-tenant, cloud-based video-sharing platform with PHP as the backend (aws cloud) in a matter of weeks.

I once wrote, from scratch (frameworks excluded), an entire backend (and front-end) of version 1 of a hybrid mobile app (backend in PHP) for a medium-size logistics company in a matter of less than 2 months.

I have other examples, but life is too short trying to convince "haters" that they might not be 100% correct.

I was the only developer on both of those projects. Your mileage may vary :)

Can you attribute that specifically to PHP making that possible? Why couldn't an equivalently capable peer use Python to do the same?

So the claim was that PHP "gotchas" are a drain on productivity. I'm not trying to compare with other languages, but I think my anecdata shows that, at least in my case, when you understand the tools PHP can be a very productive one.

Certainly gotchas are a drain on productivity. But I don't think this applies more to PHP than any other language I've used. The fact is, if you are less familiar with the language then you won't be as productive.

I personally spend a lot of time hopping among technologies and I always lean heavily on documentation. PHP has pretty good documentation, and this helps a lot in my opinion. I would guess that a lot of developers don't read the docs and just assume that something in a less-familiar language will work exactly like they expect it to, and then call this a "gotcha" when it doesn't.

Why is php development quicker?

Because of spaces vs tabs additional overhead. Packages vs built-in libruaries. RAD frameworks like laravel vs Django.

PHP has excellent development experience. After updating your code, you can just reload the page. That's it. It's seamless. This is something that I sorely miss now that I'm a .NET developer.

Also, the PHP ecosystem is friendly to beginners. Compare these authentication docs for a PHP project vs a .NET project:

Laravel (PHP): https://laravel.com/docs/7.x/authentication ASP.NET Core (.NET): https://docs.microsoft.com/en-us/aspnet/core/security/authen...

> After updating your code, you can just reload the page. That's it. It's seamless.

This is available with many other languages as well, i.e. https://github.com/cosmtrek/air

It may require an external tool, but the deployment experience is a lot simpler for Go than PHP.

I think in all the critical pain points all relatively popular languages used for web development have a well thought out story. I think there's nothing about the "pipeline" that's a huge bottleneck for a well-seasoned developer anymore. At least there shouldn't be. It's more about (a) getting things spec'd out well, and (b) execution.

Sounds like a jr dev misstep... you're not really bringing up any key points.

It takes 5 seconds on Google to find a myriad complaints about weird, unexpected, and downright incorrect things that PHP does. That wasn't the point of my reply. The point was that language choice CAN affect productivity. And having a bunch of gotchas is something that will negatively affect productivity. I simply gave the first example that popped into my head that actually tripped me up.

Unit tests would have caught this, if you wrote them.

>Unit tests would have caught this, if you wrote them.

If I hadn't considered string-number-keys in my code, I would also have forgotten about them in my unit tests. Maybe you're different.

Assuming you thought to test using a string that's all digits. You have to know about PHP's brokenness to even think to check that. In a sane language, it doesn't matter what the contents of the strings are, they're just strings.

My unit tests did not cover all possible strings, unfortunately.

RE: string -> int, I'm not able to replicate this.

https://repl.it/@JadoJodo/SelfreliantEdibleUsers

edit: Not trying to discount your feelings overall, but just curious about that specific example.

Most people don't use a production version of php.ini, I'm fairly certain you can turn this off and on in there. I've only run into this on my personal projects (where I don't care too much about the configuration) but never at work.

You example doesn't work because you tried to access the element with a string, which was ALSO converted to an int.

https://repl.it/repls/CompetentBlondInstructions

Here I changed your string index to an int and it still says success!

The PHP deal-breaker is that it casts[0] string keys that contain "valid decimal integers" to "the integer type"?

Seems like a fairly minor language quirk (of which almost every language has) rather than a huge feature that makes one want to avoid the language at all cost.

Of course, feel free to make your own choice when picking a language, but I don't think this is a compelling reason why one would always want to avoid using PHP for their web backend.

[0]: https://www.php.net/manual/en/language.types.array.php

I'm getting quite tired of the nonsense straw men in this discussion.

Do you truly believe that I articulated that there was exactly one reason that I think PHP hinders developer productivity?

And of course, we brought out the old "every language has quirks" apology. Yes, you can bang a nail in with a rock. But, don't. Use a hammer.

Do better, please.

I wonder how many developers hate PHP because one is just supposed to hate PHP.

I'm sure there are many with well-thought-out reasoning though, like seen in this thread.

It's useful to keep an open mind about things though. I'm probably more a PHP fan, but I can't say that I'm a huge fan of its programming style. It's much more enjoyable to me to churn out applications in .NET or in Ruby, but it's hard to argue with the speed at which I can develop in PHP or with the level of support online for doing so.

I think you're missing a third group of PHP haters that's actually a majority: those who've used PHP, sometimes extensively, and built up a backlog of "this is stupid" bits in their head about it. They don't have deeply reflective reasons or a strong theoretical basis for hating it, they've just suffered with it for a good while, found some better alternative, and are now sceptical that any amount of improvement will be able to outweigh the friction they "know" will be there if they try to come back.

So the anti-PHP feeling for this group is broad but shallow. Here's what I think is interesting: JavaScript is here right now. Like PHP, it's incredibly popular, almost mandatory to know in some degreee, and using it for any length of time causes one to build up a catalog of "WTF?" and workarounds and "use this library instead" and a constant churn of "it's great if you use <some framework or conceptual approach> on top of it".

I used PHP a lot, and found it quite pleasant with Laravel, but the latent pool of distaste means I'll never go back. I work heavily with JS now, and can feel that wide puddle of "why do I have to put up with this?" spreading, even while other parts are really good.

I don't know how you overcome this, broadly. Perhaps it doesn't matter, because I think this group (and I'm part of it) blows with the wind more than most, and if the winds shift back, we'll probably come along.

That's a really good point. Nothing is perfect, and frameworks are no different, so after awhile the friction points come to the fore.

Also, I have a theory that with the more common languages, you obviously find a much broader user base of beginner-level programmers, or, worse, programmers who just don't care about quality, which translates to more dysfunctional code in the community in general. My coworker at one company did not have good things to say about PHP, but when he had to take over a PHP project of mine when I left the company, he said it was some of the most well-written PHP he's ever seen -- organized, easy to follow and modify, etc. He didn't even realize PHP could be written in an eloquent fashion. (Not to brag, I've written plenty of bad code too.) Point being that if all you see in a certain language is jumbled spaghetti code, it's easy to think of it as a bad language.

A good programmer should be able to create eloquent code in any language.

Edit: Realized after posting I may have sounded like I thought you were not a good programmer -- that's not what I was saying at all! You can write eloquent code and still be frustrated with what the framework or community forces upon you.

It would be interesting to see a ranking of programming languages by the rate at which they accrue ill-will with continued use :)

It's a very good point: the more widespread a language, the larger the proportion of users will be beginners, who will almost certainly confuse their own inexperience with language-driven frustration (again, c.f. JavaScript). My pet theory on the broad appeal of PHP is that it coincided with the easy availability of shared hosting accounts where PHP was the default scripting environment available. The barrier to entry for blogs, shopping carts, forums, everything was incredibly low, leading to an explosion of software, tutorials, walkthroughs, and community that was heavily slanted towards beginners, dilettants and "low end" programmers". I made a living as one for several years, doing PHP for $5-10k jobs, and there was endless small-business work in this segment.

If modpython had worked as well as modphp, the world might look very different today.

Yeah I mean the exact super dictionary bug that GP mentions also haunts Javascript, everything will be converted to string. But if you use Map and Set...

As you said, there's almost always a solution to avoid the pitfalls but that makes you more and more "unhappy" with the language over time. I'm one of the rare people who can answer most JS trick-questions correctly, and that puddle has been building for many years (let's say more than 10).

On the other side, I'm very pragmatic and using tools like ESLint and Typescript (well that's just JS with SUPER pragmatic typing in my eyes) started to make it a joy again in the last few years. I hope the trend continues. I can't say the same for my PHP experience.

I think this is probably an example of the larger tendency of people to overrate the importance of whatever it is they directly work with, and its effect on their workflow. Like a carpenter insisting that using a certain brand of hammer has an effect on the habitability of the resulting house.

After years of using a lot of products and seeing which ones succeed and which ones fail, I question whether there's much of a connection between code quality and product success, assuming of course that the code isn't bad enough that it prevents the use of the product.

Heck, I'm not even sure there's a strong correlation between basic product function and success, at least in the enterprise space; I've seen a number of successful products that barely even work. Seems like market positioning and sales are the bigger factor.

> I think this is probably an example of the larger tendency of people to overrate the importance of whatever it is they directly work with, and its effect on their workflow. Like a carpenter insisting that using a certain brand of hammer has an effect on the habitability of the resulting house.

One brand of hammer causes RSI. This brand of hammer tends to bend nails unless they're made of titanium alloy at 80% higher cost. The houses built are basically fine, but they have quirks as a result of the builders trying to avoid having to use nails. You lose 10% of your workforce after every project to medical leave and burnout. Everything is fine because people keep buying houses (there's a shortage).

Coming from Java, the one pet peeve I have is the automatic type conversion. I just find that I never really know what my variables are _really_ holding.

It's one of those foundational issues that I just can't get over.

...but it's my personal problem - I don't hate PHP.

Work as a PHP dev, in a PHP/JS shop.

In all new work we require static typing on method parameters and defined return types. Of course, if your type is 'array' it could be an array of anything but we also try to avoid that and use collection classes. It honestly feels a lot like Java now, without the compile step.

I do the same in Python with type hinting. It's not actual typing, but at least there are tools that can help call us on our dumbass bullshit.

Edit: and by "our" dumbass bullshit, I mostly mean when we thoughtlessly return type T when we claimed we'd return type U

We do similar (strict_types, declare parameter and return types, etc), but don't go as far as the Java-style collection classes except where absolutely necessary.

As a mostly-acceptable alternative, we just type hint as array and document the actual containing types in the phpdoc block and run phan for static analysis to catch any potential screwups.

    /**
     * Method for converting Foos into Bars
     *
     * @param Foo[] $foos
     * @return Bar[]
     */
    function convertFoosToBars(array $foos): array
    {
        // ...
    }

In theory this isn't perfect. In practice we haven't run into any issues yet.

>I wonder if most developers that trash on PHP for trivial issues like seen in this thread haven't been using it for many years, or had a bad experience (e.g. maintaining a legacy app).

I wouldn't be surprised if many of them don't even have that experience. I've found a lot of people just parrot whatever someone else wrote or said without much thought. The tribalism within the development community is approaching what you'll find with in gaming, sports and even politics.

Not gonna lie my #1 complaint is that PHP jobs on average pay like shit in comparison to most other things. I don't want to work with it solely because it has no value on my resume.

That being said the biggest argument for PHP is productivity and I just prefer Ruby + Rails for that. Honestly though I will say I find PHP more pleasant to work with than Python these days.

>I wonder if most developers that trash on PHP for trivial issues like seen in this thread haven't been using it for many years, or had a bad experience (e.g. maintaining a legacy app).

Think this is true. I am one of those php haters, although I wouldn't trash it. I worked with 4 and 5 and the transition between the two, so it is a while ago. I am not fondly remembering that time and have moved to other branches than web development to evade it.

That being said, if I would go back to web development, I would have a look at it. Why not?

Why would I ever want to use it again after php5? It might be better now but the competition is so much better than what php5 was that I have zero reason to revisit the language.

Some people simply have reasonable standards. I tried for years to hire a PHP dev. I never found a single one. I found tons of people who had PHP on their resume, and not a single one of them was anything close to competent. PHP only makes hiring easy if you don't care about the quality of work that gets done. I can hire a million PHP monkeys, but everyone who has the right combination of intelligence and conscientiousness to be a competent software developer moves on from PHP after 2 or 3 years as they discover what it is.

You can hire "good programmers" and ask them to write PHP - Facebook does

Facebook, Slack, Etsy, the list goes on. In fact, I think all thosr companies are actually hiring right now, unlike many of those advanced non-PHP shops.

Facebook writes Hack, which is nontrivially different from PHP, and those differences matter.

I doubt that Facebook tries to hire Hack devs off the street. No one uses Hack except FB. They hire PHP developers and teach them Hack in boot camps.

The point being, you can hire good php devs.

Facebook probably just hires super bright developers, not PHP developers per se. Those developers can pick up Hack in a couple of months.

Normally, bright developers acquire a new language* within a few weeks, if they already know the paradigm from another language. Hack is OOP, and so are many others, so I would expect a bright developer to learn hack in 2-3 weeks, not months.

Heck, I just read the docs of hack for 2 hours, and I already got a good sense of what the language can do. I worked with PHP internals, and a bunch of other languages in my career.

* as language we define the language, its syntax and semantics, not any other library or the ecosystem. And yes, the standard library is still just a library. Knowing a list of functions and parameters does not mean knowing a language.

Well Ruby is OOP, is it gonna be super easy for me to get a java web development job? All things being equal a hiring company will go for someone with 3 years java experience over my 8 years Ruby experience. Facebook has no choice since no one knows their language, but most other companies will hire someone with the particular experience of their stack if possible.

Many employers use php because it allows keeping salaries down, though. So your advice would not work for those.

The parent post complained about the quality not salary level of PHP programmers, though. The parent wants a quality PHP programmer, you want to keep salaries down - there is an acceptable tradeoff, somewhere.

The parent poster didn't complain about anything, he pointed out the flaw in the grandparent poster's claim.

No, facebook doesn't. The good programmers facebook hires don't work on the legacy PHP code. They do stuff like sigma. Also, I am not describing a problem, I am pointing out that their perceived problem doesn't exist. If I can hire a good programmer and make them write PHP, I could also hire the good programmer and let them write in a tolerable language, so the mythical "its easy to find PHP devs and impossible to find anything else devs" claim is out the window.

Are you trying to hire vanilla PHP devs or framework PHP devs?

In my previous company (based in Paris, FR) we had a very hard time getting skillful PHP devs, even if there were a lot of candidates.

Reply on news.ycombinator.com