3 ms·

I wasn't bashing PHP per say but I was saying that if you are sticking with it you are going to get worse and worse jobs going forward because the market is loo

I wasn't bashing PHP per say but I was saying that if you are sticking with it you are going to get worse and worse jobs going forward because the market is looking for Python right now. Depends what you want to be building, or if you work for yourself and choose the technology. I'm building a network scanner at the moment and I have to say that even Python let alone PHP isn't really cutting it. As I've been learning Elixir (for a project in my spare time) and getting to grips with the OTP you really do start to realise that functional programming and the Actor Model amongst all the syntactic sugar is a big win. Sure if you are bashing out a PHP websites great. But if you are building something with lots of processes or parallelisation requirements PHP (or Python for that matter) is not your friend. In conclusion use the right tool for the job. As everyone knows we should all stop using PHP and start using lisp, given the choice :-) http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html

stanmancan 11y ago
Of course you don't want to use a hammer to dig a hole. Picking the right tool for the job is necessary regardless of what line of work you're in. With that being said, you can accomplish some pretty interesting things if you think outside the box a little bit. I wrote a small application to perform an ETL between various data sources (MySQL, an old version of MSSQL, various third party API's, CSVs). I populate a queue and spawn up as many PHP processes as I want/need (php -f /thread.php {$id}) and each one runs on their own, grabbing an item from the queue, processing it, then grabbing another one. Currently I run about 64 of these "threads" at a time with no issues, which allows me to sync a few million records relatively quickly. Best tool for the job? No. Does it work? Hell yeah. Had I tried to learn a new language to get this done I probably never would have finished it or it would be way harder for me to maintain/debug in a language I'm not familiar with or use often enough to efficiently troubleshoot when something comes up weeks/months/years down the road.

stanmancan 11y ago

Of course you don't want to use a hammer to dig a hole. Picking the right tool for the job is necessary regardless of what line of work you're in. With that being said, you can accomplish some pretty interesting things if you think outside the box a little bit. I wrote a small application to perform an ETL between various data sources (MySQL, an old version of MSSQL, various third party API's, CSVs). I populate a queue and spawn up as many PHP processes as I want/need (php -f /thread.php {$id}) and each one runs on their own, grabbing an item from the queue, processing it, then grabbing another one. Currently I run about 64 of these "threads" at a time with no issues, which allows me to sync a few million records relatively quickly. Best tool for the job? No. Does it work? Hell yeah. Had I tried to learn a new language to get this done I probably never would have finished it or it would be way harder for me to maintain/debug in a language I'm not familiar with or use often enough to efficiently troubleshoot when something comes up weeks/months/years down the road.