Great projects exist in every language from COBOL to Lisp.
Taking PHP Seriously
631–640 of 673 posts
Re: Taking PHP Seriously
#632Earlier quoted context omitted.
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.
If you are running .NET code in production on a non-Windows platform today, then you and your team are probably braver and more willing to work around issues than most. I hope that running .NET code on Linux becomes the common case, but I suspect that we are still a couple of years away from that.
It might not be exactly what you had in mind as 'in production', but it's probably worth noting that Unity uses Mono as a core component, and it seems to be fairly popular on non-Windows platforms.
Re: Taking PHP Seriously
#633I 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…
Up until the mid-2000s, if you wanted an easy up-and running web application environment without paying Microsoft, PHP plus MySQL was the only game in town. There were alternatives, but they invariably involved maintaining your own server and doing quite a bit of legwork yourself. The was no Heroku, no AWS, and tooling for python, ruby, and other environments required much more expertise to simply get an app responding on port 80.
Almost any big app you can point to that is built in PHP today was bootstrapped in this environment.
I did a lot of PHP from the late '90s up until 2008. Maybe things have changed in the intervening eight years, but I cant say I miss it.
Re: Taking PHP Seriously
#634Earlier quoted context omitted.
Yeah, but you also have to fork a whole process per request to do it. Process fork, CoW overhead every time you mutate a page, and a full OS thread per request. Oh, and let's not forget negotiating a new database connection per request. I think by the time you've added up all those overheads, you're not off to a scalable start. It's possible to work around the limitations, but it's not easy.
> Yeah, but you also have to fork a whole process per request to do it. Eh, any PHP developer worth their salt is implementing PHP-FPM. The days of forking expensive Apache processes have long been over.
The whole reason your Apache was (kind of) expensive to fork was PHP. You've only moved that forking to the PHP-FPM process.
But that said, forking processes is not really a problem unless you do really long lived connections (such as longpoll handlers). Many other languages do that. Not many other languages have kept the CGI-like request model that PHP has, though.
It encourages things like parsing code or even opening database connections on every request, unless you cache them. (Which you probably do if you are a PHP developer. But it's not always as automatic as one would hope. Have you checked your application still fits in the cache you set up?)
Re: Taking PHP Seriously
#635Earlier quoted context omitted.
>>Why are there no other "competitors" in this space? There are. Any language that supports either fastcgi, or runs as an apache plugin (or similar) functions in the "each request starts new" space. There's certainly others, but Python and Perl are both good examples. Starting new with each request does, of course, mean lots of re-work that shouldn't have to be done with each request. It does initially keep complexit…
Can you set up Python to have the same pattern as PHP? I've always had to proxy the web server to the Python process running HTTP.
Back in the day, mod_python also supported PSP (Python Server Pages), which was similar to PHP/ASP in that it allowed you to write a file as a mix of HTML and Python code inside delimiting tags.
Re: Taking PHP Seriously
#636The biggest issues I see with the language didn't made into this list: for instance, I can think about more serious issues like accessing the wrong variable name does not returning an error, assignment and initialization being the same (thus also suffering the same issues related to wrong names), various surprising type conversions, defaults, and so on. I guess it all boils down to the mindset of the language itself, as the article says.
However, I disagree that "other languages do not work like that thus are not as easy to test". You can implement this in any way you like in any other language. You can implement your webserver by forking a new process at every call. You can even use a worker that communicates to a different hot-swappable process. It can efficient as you want - copying the whole data around, sending file descriptors, etc. The alternatives are endless.
PHP may be "interpreted and hot-swappable" by default, but that's an accident from it's design and it only works like that - if you try to use it as a long-running process, you'll run into a lot of issues. It's also terribly inefficient - have you ever developed a web interface for an embedded platform? A really embedded one, like 32MB of memory, shared with the application itself?
I guess in the end it boils down to the duct tape analogy: it's terribly fast to prototype something with duct tape and scraps and you can join a multitude of materials in a very simple way - just put everything in place and cover with enough tape to hold it together.
Surely, it works.. but that's about it.
Re: Taking PHP Seriously
#637Earlier quoted context omitted.
> we should definitely stop using them That will never happen, you can't write code like this in Rust: Customers Even when the previous code is an abomination, it is absolutely easy to write, this is why languages like PHP are a success, the barrier to entry is definitely low. The issue comes when the whole industry buys the idea that PHP equals bad code, fail to appreciate the progress the language has had in the la…
Why would I ever want to access the database from the presentation layer? That you cannot write that abomination in rust for me it is a clear advantage, not a disadvantage. And still I can't understand how can you compare php with rust. A much more apple to apple comparison would have been with WebSharper.
Because when you're just some guy that wants an answer to the question "how do I get some things from a database into a web page", the answer that starts "Well first go set up a VPS..." and hits "There's this thing called MVC" somewhere in the middle is not something someone who just wants to put a list of things into a web page is going to listen to.
Then a month later that guy that pulled those couple things into a web page is going to go "Hey, maybe I could make a thing to manage those.". And he's going to learn more.
Then a month later he's going to have another bright idea.
And suddenly someone with no programming background is a PHP programmer, and he's putting together ugly but functional websites and everyone is looking and going "MAN PHP IS AN AWFUL LANGUAGE".
There's a huge contingent of people that are maybe moderately technically savvy but are not programmers and are not necessarily interested in deliberately becoming one. These are the people that end up setting up entire businesses in some Lovecraftian Excel sheet. PHP is a language with a learning curve (even for a non-programmer), not a learning cliff, and it makes it really easy for these people.
Re: Taking PHP Seriously
#638Earlier quoted context omitted.
Underrated comment. To expand on this, static website generators are best for generating documentation and small blogs. It falls apart when you have a large often-changing content. This is where PHP is still king of the web.
> large often-changing content. This is where PHP is still king of the web. PHP is still widely used, but there's a myriad of other contenders: Java, ASP.NET, Python (Django,Flask,etc), Ruby (Rails), Perl, Javascript (Node,etc) and others. I'm not sure about PHP being the "king". PHP might be the most widely deployed thanks to either FB or the huge number of legacy bulletin boards and wordpress sites, but in terms of…
All of the languages you listed have a way steeper learning curve than PHP. PHP creates a lot of really small steps you can take getting from "I roughly understand HTML" to "I can build a full 3-tier MVC buzzword-of-the-day app.". For anyone not intending to become a full-fledged programmer, but instead just to add a little bit of interactivity/dynamism to their website, it's still the path of least resistance.
Re: Taking PHP Seriously
#639Wordpress succeeded because they were using PHP, because during the 2000's it was very easy to find a cheap shared hosting solution in PHP+MySQL. There was no cheap way to host Rails applications. And their target was people who would install Wordpress themselves on a cheap shared host. Facebook and Wikipedia probably used PHP because many developers knew it, and the reason was... That there was many cheap shared hos…
The reason Wikipedia - or, rather, MediaWiki - uses PHP is because Magnus Manske was going to write something to replace UseMod, and thought he'd try this "PHP" thing he'd heard of.
It was his first PHP project.
(And why didn't Wikipedia have a visual editor until 2013, rather than 2005? Because wikitext syntax was literally defined as "whatever this series of PHP regexps does". Of small acorns, mighty oaks of technical debt can grow ...)
Anyone who claims anything even vaguely in the direction of "PHP is good 'cos Wikipedia uses it" is talking rubbish.
Re: Taking PHP Seriously
#640Earlier quoted context omitted.
Managers caring about technical debt? You must live in a parallel universe. They may care about maintenance costs, but that is not really the same thing.
the end result of technical debt ==> maintenance costs makes it same enough.
Looking at things from the other side: being a manager and trying to sell projects to reduce technical debt is really freaking hard in a world of short-term outlooks and revolving door of CEOs that want to improve numbers this quarter or the next, not a few years down the road.