Personally, I'm not bothering to learn any new languages, stacks or APIs and will stick with what I know. AI will eventually (2-10 years) end up completely re-writing your whole program stack in machine code in whatever ISA without any bugs. The future of programming is a prompt engineer, write it in psudo code and english and output fully tested machine code.
PHP popularity is decreasing because there are better tools for the same niche today. The same happened for Perl in 00s. The same is happening for every web backend language, as JavaScript is becoming ubique due to it being the de facto and only choice for the web frontend.
Maybe PHP can be made better, but it would need some radical changes and then the question is that if it’s worth the effort and maybe to pick up some of the new tools instead.
For JS, you need to setup a listener like PM2 and point it at the folder, but once that is done, you can drag and drop and index.js file into place and it'll all work as expected.
People always seem to come up with the argument that you can drop an index.php in a folder and be done with it. Only nobody uses php that way since decades.
Modern php code uses Frameworks, Package mangers, opcode caching, and application servers.
It’s just that other languages don’t carry all the cruft php has in its heritage…
The drop index.php into a folder is the only way I use PHP now.
Back when I was building applications in PHP it was all frameworks. package managers, op code caching, etc. But I no longer do PHP development but for my own personal websites I still use PHP but in that most minimal form.
Exactly, if one is not developing PHP for the enterprise (maybe some non-enterprise simple projects still use opcodes though? lol), it's silly not to leverage index.php for all it's worth :-)
So where is the hyper-simple JS equivalent for that class of non-enterprise projects, is what I wonder...the enterprise stuff has always been heavy and loads projects down with maintenance debt.
There are projects between hobby users and Facebook, believe it or not :-)
I actually like using a reliable package manager, a wide ecosystem of good packages, and modern language features. There is nothing "heavy" about modern PHP, unless you want it to.
It changes deployment because you need to flush the opcache after deploying new code, for example; you need to install composer packages, restart the app server (if you use one), etc. I mean obviously you still upload files, but there are more steps involved in a proper deployment.
Once you start getting into zero-downtime deployments, you'll quickly see the need for both application servers like Swoole or RoadRunner, as well as strategies that don't leave requests in the air with half the code from the old version and the other half with the new one.
Let HackerNews hobby programmers snark all they want, those are very real problems with very real solutions.
I mean... using a symlink to the deployment root gives a quick atomic swap. You update the link, then reload the server config, no downtime and no partial deployments during a request. This also solves for the opcache freshness as well if I recall correctly. (It's been a little bit since I've done any PHP work)
Of course, you can do that. It’s the strategy Etsy used, for example. Point still standing, that makes deployments definitely more complex than just „uploading a file“.
And then again, you’ll end up wondering why your servers should waste cycles upon cycles for executing the same bootstrap code over and over again, if they could instead only do that once, keep the app in memory, and only execute the request handling code… and just like that, you’ll end up with Octane, or Swoole, or what-have-you.
What I like about PHP is that it's not just batteries-included, it's "Entire Batteries Plus Store Included". The standard library is huge, documented, and also features 15 years of accumulated notes and discussion right on php.net.
The tendency to have a npm package for everything is overwhelming because you end up with choice paralysis and risk on picking "Oh, you picked CSV-to-array library #823, it's the buggy/insecure/unmaintained one."
File reading excluded, CSV to array is like two generator functions and a main, even with rudimentary schema support. No reason to add a dependency at all.
… in your echo chamber. I know first hand of multiple very large corps doing that (one of them being a bank and this is their payment api) and very many smaller shops. Sure, we recommend against it, but saying it’s decades ago like that is nonsense; many people do this because it’s convenient.
Oh that's easy - just install 10 insecure npm packages that each install another 10 npm packages (some of which are even maintained!) then make sure you remember to bundle it up in a nice, heavy electron wrapper. Then you're all ready to distribute it via some random App Store - just don't forget to charge a monthly subscription while you're at it. /s
Don't do this to me, I maintained one of these projects years ago, and am still somehow billed $0.30 a month for the privilege of the original dev having used Amazon tools for it :D
The pain is real! Speaking of Amazon - AWS CDK is promoting lots of terrible practises mostly built on barely supportable TS/JS, it's so... so terrible.
I've been doing web development since before the <table> tag was introduced.
> just install 10 insecure npm packages that each install another 10 npm packages
I still don't understand why companies are fine with this.
At my last job, even principal and staff level developers needed every Windows or Mac application install vetted by IT. We had real time system monitoring on all employee workstations that ate up half the RAM and CPU resources and constantly kicked us off the VPN for even the slightest quirk (including the CPU redlining due to scanning).
But npm dependencies? Nothing. Install whatever you want and push it to production.
This is an S&P 500 company that deals with tons of PII.
Because the working part of an organisation such as the one you describe tries to continually optimize away these restrictions. NPM (et al) is a good way to obfuscate the fact you're pulling unknown code to get shit done and processes haven't caught up yet.
I'm not saying this is good, but the reality with these company-internal restrictions is, that the most productive people find ways around them and are rewarded for it.
What is the PHP equivalent of writing your front end and back end in the same language so you can share libraries and data and not have to switch gears between two different languages each time you look up or down the stack?
There is a HUGE advantage to using the same language in the browser and on the server, and PHP isn't ever going to displace JavaScript in the browser. So JavaScript it is. That ship sailed a LONG time ago.
I like switching gears, I truly don’t find it an advantage using the language for both. Have separate languages makes the distinction between backend world and front end world very clear. Also the backend code is mostly data manipulation and the front end code is mostly rendering so there is very little overlap in similar functions for both. The separation helps keep things tidy in my brain.
I much prefer not having to write JavaScript everywhere, not every problem is a nail and not every solution requires a hammer.
> What is the PHP equivalent of writing your front end and back end in the same language so you can share libraries and data and not have to switch gears between two different languages each time you look up or down the stack?
You can simply compile your PHP code to wasm with emscripten, and then run it in the browser. Pretty straightforward. No more switching gears.
The value is really not in sharing code, but rather sharing developers. Instead of having to assemble and keep happy a diverse group of specialized professionals, you can just hire and fire a bunch of cheap JS folks, who are easily replaceable.
Offshoring already takes care of the cheap developers part.
When people get what is peanuts in local currency of the owner company, whatever they are using doesn't matter and most sweet shops are experts in everything.
I can also tell that at the level I work on, salaries are the same regardless of FE, BE, DevOps, ...., specially because no one has a single role.
toyg makes a good point about sharing developers, but also sharing code is important, especially for efficient server side rendering, with view code that runs on both the server and the browser.
The point is it takes fewer people (or even the same person) to write less code (instead of writing everything twice, then trying to keep them in sync forever).
There's a fascinating deep discussion about SveltKit and other frameworks here:
Reacting To Web Hot Takes from Rich Harris - SVELTE STUFF
Well "place an index.php file in a folder to deploy" is a lot of server (maybe Apache / PHP) running to support that.
Node typically IS the server. So, you could install express and have a simple web server listening on a port and serving up html or json in about 5 lines of code. Unlike PHP Node is not, in itself, a templating language. So if you want to render HTML pages you'd also need to install something like EJS, but generally node servers are just serving up JSON API, and your frontend would be some frontend framework (React, angular, vue). Although all of that is trending back the other way with NextJS the old is new again and server-side rendering is the hotness again.
Another option is to use a framework like NestJS. With that you do
# install the nest cli (only needed for starting a new project)
npm i -g @nestjs/cli
# scaffolds a new project
nest new project-name
cd project-name
# node server is now running on port 3000
npm start
For easy deploy. That was kinda Heroku's thing. You just "git push" a node project and it magically knows how to deploy it, but Heroku got bought by Sales Force and murdered from my understanding. There are a lot of alternatives though. AWS, Azure, Google, CloudFlare, Digital Ocean, etc, etc all have similar offerings where you just push a node project to git and it deploys automagically.
Alternatively you can use AWS Lambda / Azure functions (or a dozen other "serverless" solutions) and you can just drop js files (functions) and they run on demand.
For a ProcessWire alternative there are a ton of options. A few I've seen are: Ghost, ButterCMS, Strapi
Render.com, Fly.io, northflank. And I actually like AWS lambdas, so great option for me is SST.dev, which wraps AWS CDK, and provides an actual live development workflow with actual AWS resources.
I’ve been using fly.io for little things and it’s remarkably nice and easy to use. I can’t vouch for large scale projects, but for little things you want to experiment with it’s a joy.
I have a hobby app that is index.html and I just manually add <script> tags to load libraries. No build step, I just use GitHub to cloudFlare pages to host.
I would stick with Laravel or something like that if I were you. The rest is good for your resume, but if you don’t need that, I would forgo the misery that is js/ts dev.
While you may pick, most developers do not. You are not the most developers, as you are special and probably much more talented.
They pick JS because they know the language best and are more productive in it than in Laravel. There is nothing Laravel can do about it - being best is not going to change the direction, because the limiting factor is the knowledge of programming languages of most of developers.
They picked JS for the server because they have a choice in what languages they can run on the server, but they don't have a choice about what languages they can run in the browser, so JavaScript it is.
There are HUGE advantages and efficiencies to using the same language in the browser and the server.
Most developers are (rightfully) lazy and simply don't want to learn and juggle two different languages in two different places, when they can use simply one language everywhere.
For example, when switching between PHP and JavaScript, you have to remember that the ?: ternary conditional operator in PHP has idiotic left-associativity, so you have to use extra parenthesis to disambiguate it, while the identical looking ?: ternary operator in JavaScript and all other languages has sane right-associativity.
"I'm not a real programmer. I throw together things until it works then I move on. The real programmers will say Yeah it works but you're leaking memory everywhere. Perhaps we should fix that. I'll just restart Apache every 10 requests." -Rasmus Lerdorf
"I don't know how to stop it, there was never any intent to write a programming language [...] I have absolutely no idea how to write a programming language, I just kept adding the next logical step on the way." -Rasmus Lerdorf
"We have things like protected properties. We have abstract methods. We have all this stuff that your computer science teacher told you you should be using. I don't care about this crap at all." -Rasmus Lerdorf
Don't be such an apologist for terrible careless programming language design, expecting professional programmers to tolerate IDE's "yelling at them" about unforced language design flaws and loaded footguns, using terribly designed languages that were mindlessly thrown together by anti-intellectual amateurs like Rasmus Lerdorf, a self proclaimed "not a real programmer", who says he doesn't even like programming, who doesn't even know the difference between left and right associativity, or even "care about this crap at all".
"We have things like protected properties. We have abstract methods. We have all this stuff that your computer science teacher told you you should be using. I don't care about this crap at all." -Rasmus Lerdorf
"There are people who actually like programming. I don't understand why they like programming." -Rasmus Lerdorf
"I'm not a real programmer. I throw together things until it works then I move on. The real programmers will say "Yeah it works but you're leaking memory everywhere. Perhaps we should fix that." I’ll just restart Apache every 10 requests." -Rasmus Lerdorf
"I don't know how to stop it, there was never any intent to write a programming language [...] I have absolutely no idea how to write a programming language, I just kept adding the next logical step on the way." -Rasmus Lerdorf
"Using these toolkits is like trying to make a bookshelf out of mashed potatoes." -Jamie Zawinski
"I used to think that PHP was the biggest, stinkiest dump that the computer industry had taken on my life in a decade. Then I started needing to do things that could only be accomplished in AppleScript." -Jamie Zawinski
"From what I've seen, PHP isn't so much a language as a random collection of arbitrary stuff, a virtual explosion at the keyword and function factory. Bear in mind this is coming from a guy who was weaned on BASIC, a language that gets about as much respect as Rodney Dangerfield. So I am not unfamiliar with the genre." -Jeff Atwood
On the other hand, Anders Hejlsberg is a highly skilled, careful, conscientious, experienced professional programming language designer, who actually knows what he's doing, and LIKES programming.
And as a professional programmer who's been writing lots of code in many languages since the early 1980's, I much prefer and enjoy using his well designed IDEs and programming languages like Turbo Pascal, Delphi, C#, and TypeScript, to carelessly hacked together fractals of bad design like PHP.
And you're still totally missing the point about the advantages of using one programming language on both the client an server side, sharing libraries, data, APIs, mental energy, and effort.
If you were really a professional programmer, you wouldn't be stuck in a rut using and apologizing for PHP, because you would be capable of learning and using many other vastly superior and more powerful programming languages and tools than PHP, and you wouldn't have to waste your time and mental effort rationalizing and making excuses, remembering to avoid so many unforced foot guns and idiotic bad design fractals, and carefully and defensively working around all of its flaws, while getting "yelled at by your IDE" all the time, instead of actually spending your finite time and energy solving problems.
"The peak computer speed doubles each year and thus is given by a simple function of time. Specifically, S = 2^(Year-1984), in which S is the peak computer speed attained during each year, expressed in MIPS." -Wikipedia, Joy’s law (computing)
"C++++-= is the new language that is a little more than C++ and a lot less." -Bill Joy
"You can't prove anything about a program written in C or FORTRAN. C is PEEK and POKE with syntactic sugar." -Bill Joy
"You can drive a car by looking in the rear view mirror as long as nothing is ahead of you. Not enough software professionals are engaged in forward thinking." -Bill Joy
“Java is C++ without the guns, knives, and clubs.” -James Gosling
A Conversation with Language Creators: Guido, James, Anders and Larry [video]
"My favorite is always the billion dollar mistake of having null in the language. And since JavaScript has both null and undefined, it's the two billion dollar mistake." -Anders Hejlsberg
"It is by far the most problematic part of language design. And it's a single value that -- ha ha ha ha -- that if only that wasn't there, imagine all the problems we wouldn't have, right? If type systems were designed that way. And some type systems are, and some type systems are getting there, but boy, trying to retrofit that on top of a type system that has null in the first place is quite an undertaking." -Anders Hejlsberg
Andrew Hejlsberg:
>Maybe I'll just add, with language design, you know one of the things that's interesting, you look at all of us old geezers sitting up here, and we're proof positive that languages move slowly.
>A lot of people make the mistake of thinking that languages move at the same speed as hardware or all of the other technologies that we live with.
>But languages are much more like math and much more like the human brain, and they all have evolved slowly. And we're still programming in languages that were invented 50 years ago. All the the principles of functional programming were though of more than 50 years ago.
>I do think one of the things that is luckily happening is that, like as Larry says, everyone's borrowing from everyone, languages are becoming more multi-paradigm.
>I think it's wrong to talk about "Oh, I only like object oriented programming languages, or I only like imperative programming, or functional programming".
>It's important to look at where is the research, and where is the new thinking, and where are new paradigms that are interesting, and then try to incorporate them, but do so tastefully in a sense, and work them into whatever is there already.
>And I think we're all learning a lot from functional programming languages these days. I certainly feel like I am. Because a lot of interesting research has happened there. But functional programming is imperfect. And no one writes pure functional programs. I mean, because they don't exist.
>It's all about how can you tastefully sneak in mutation in ways that you can better reason about. As opposed to mutation and free threading for everyone. And that's like just a recipe for disaster.
"I have a feature that I am sort of jealous of because it's appearing in more and more other languages: pattern matching. And I cannot come up wit...
That's exactly Jeff Atwood's point, which I quoted above (and will repeat here):
"From my perspective, the point of all these "PHP is broken" rants is not just to complain, but to help educate and potentially warn off new coders starting new codebases. Some fine, even historic work has been done in PHP despite the madness, unquestionably. But now we need to work together to fix what is broken. The best way to fix the PHP problem at this point is to make the alternatives so outstanding that the choice of the better hammer becomes obvious." -Jeff Atwood
Leaning hard into the IDE (or ChatGPT these days) because your language design is flawed is a hella/totally stereotypical "West Coast" thing to do, as described in "Evolution of Lisp", "Worse is Better", and "History of T", and exemplified by Interlisp and Warren Teitelman's "pervasive philosophy of user interface design" and implementation of "DWIM".
If your language isn't terribly designed, then your IDE doesn't have to be such a complex non-deterministic Rube Goldberg machine, papering over the languages flaws, haphazardly guessing about your intent, "yelling at you" all the time about potential foot-guns and misunderstandings.
As you might guess, I'm firmly in the "East Coast" MacLisp / Emacs camp, because that's what I learned to program in the 80's. I can't stand most IDEs (except for the original Lisp Machines, and Emacs of course), especially when they keep popping up hyperactive completion menus that steal the keyboard input focus and spew paragraphs of unexpected boilerplate diarrhea into my buffer whenever I dare to type ahead quickly and hit return.
But my point is that you can have and should demand the best of both coasts, unless you start off with a Shitty West Coast Programming Language or a Shitty East Coast IDE.
(Of course those philosophies are no longer bound to the geographical coasts they're named after, that's just how those papers describe their origin.)
Jeff Atwood's point an my point is that we should demand both well designed programming languages AND well designed IDEs, not make excuses for and paper over the flaws of shitty ones.
There are historic existence proofs, like Lisp Machines and Smalltalk, and we should be able to do much better now, instead of getting stuck in the past with Lisp or PHP.
I mentioned the East/West Coast dichotomy in the discussion about the conversation between Guido, James, Anders and Larry:
>DonHopkins on April 4, 2019 | parent | context | favorite | on: A Conversation with Language Creators: Guido, Jame...
>Anders Hejlsberg also made the point that types are documentation.
Programming language design is user interface design because programmers are programming language users.
>"East Coast" MacLisp tended to solve problems at a linguistic level that you could hack with text editors like Emacs, while "West Cost" Interlisp-D tended to solve the same problems with tooling like WYSIWYG DWIM IDEs.
>But if you start with a well designed linguistically sound language (Perl, ...
With GPT, I don't really find that I am more "productive" in one scripting language or another given that it has the ability to perfectly translate between them on the fly.
Perfectly? Oh really? Have you tried actually reading the code you're copying and pasting from ChatGPT into production? Are you actually letting it do all your architectural design and security auditing for you, too?
If ChatGPT is already perfectly solving all of your programming problems, then you should learn a lot more about programing, design, architecture, and security, so you can take on more challenging projects, and actually design decent APIs and architectures, instead of just paint-by-number monkey coding, and produce better more thoughtful designs and code than an LLM, because your job is already obsolete.
If you think the current crop of AI does the translation “perfectly”, you’re going to have a bad time. Or maybe not you, but your customers, client, or the poor chap that replaces you is going to have something blow up in their faces.
"From my perspective, the point of all these "PHP is broken" rants is not just to complain, but to help educate and potentially warn off new coders starting new codebases. Some fine, even historic work has been done in PHP despite the madness, unquestionably. But now we need to work together to fix what is broken. The best way to fix the PHP problem at this point is to make the alternatives so outstanding that the choice of the better hammer becomes obvious." -Jeff Atwood
javascript has the advantage that front and backend can share code, but as a language it's much worse. php at least has been able to break backwards compat to fix its worst design mistakes, and natively has typing
There are few factors why PHP popularity is decreasing, not because it is really bad. But very often other languages build its popularity on promoting how "bad" is PHP. It is also no longer fashionable as it was in the beginning, but other language promoted as such. And more.. So, I think, rebranding and good marketing could help here.
There is no Visual Studio dependency. The VS Code / editor experience is on par with most other languages and Rider is surely more than capable JetBrains based alternative
So, what’s your alternative? Python with its god-awful package management situation? Node with its „here’s a bazillion libraries for the same thing, good luck figuring out how to combine them“? Ruby with its 90ies-grade performance?
Work on transpilers to whatever is used instead and port existing libraries or support PHP frameworks in other technologies. This is to reuse existing experience and code.
PHP has already been "rebranded". When people try to dunk on PHP for supposedly being awful, people are quick to point out that that's all from "pre-PHP 5.6" and that "PHP 7/8" are bringing all kinds of excellent features, functionalities, and refinements
The author links to the person thinking that HypeScript is a good name. He says:
"The name HypeScript sounds like a logical name for me, it pays its respect to the name PHP (PHP: Hypertext Preprocessor) as well."
That would be like suggesting that IBM rebrand itself "BizCompany" to pay respect to its own name (?)
Edit: Wikipedia says "PHP was originally an abbreviation of Personal Home Page, but it now stands for the recursive initialism PHP: Hypertext Preprocessor."
PHP has been supposedly dying for 15 years. It's always been super trendy to dunk on it, but in many respects it remains the best tool for specific jobs. And that's what matters. A language's hip factor is not particularly important to me.
1) First, understand that one audience matters particularly for programming language popularity, and that is people who are starting their careers. If you learn a language and use it for a few years, it tends to be a language you continue to use throughout your careers.
Here, we have no data. But I can tell you as someone who works with a lot of early stage startups and 20-somethings who are diving headfirst into programming for their startups for the first time, the language of choice is Python, followed by Javascript of some kind.
I have a long history with PHP and dearly love it as a language, but the concern I have is that it's not getting picked up like it was. Still love using it, and boy is Laravel productive for a small team.
That said, this is anecdotal, and I don't have any data here as the programming language surveys are always so broad they don't really have this kind of segmentation to spot early trends. Curious what others are seeing however...
2) Second, as chinabot pointed out, in the short term, AI is likely to supplement the work of programmers, making certain tasks faster and more efficient. However, as AI becomes more sophisticated and capable in the long term, it has the potential to largely replace a lot of programmers. In particular, AI's ability to automate the coding process means that many routine programming jobs may become unnecessary. While this shift may take some time, it's important for those in the programming industry to keep an eye on emerging AI technologies and be prepared for changes to come.
Does that imply that languages that are for working with AI would be the better programming languages to learn? Python, Julia, C++, Java and R are the current core languages in AI land. I don't think it matters in the short term, but the AI shift looks so big it could matter a lot in coming years.
IDK, doesn't look quite as cohesive and convincing as arguments after I wrote them down, but there are some pretty interesting points in here so I'll post it anyways to add to the discussion.
PHP is still what I use for my personal projects. Sublime + SFTP plugin & any shared hosting (all also give at least 1 MySQL). Phpmyadmin I know with my eyes closed but can also default to a static db like SQLite.
It is very fast for me to start, test & itterate.
I've also tried Node but idk sometimes it can hugg memory and even crash, which just never happened with PHP.
It is a little sad but I don't really care anymore because I am not doing client work anymore.
Edit: just to add that I also never really could stand promises in async execution. Such a headache.
Edit 2: also can you believe it that with Node, the script is also the server??? Who in their right mind thought this was a good idea? Like when the script crashed, it crashed the whole app for everyone.
Sounds like you've just used node incorrectly, like without any error handling or frameworks? Pure node has always been pretty bad until very recently, the ecosystem is a big part of what has made it popular.
PHP isn't bad at all. People are just hating because it's not the greatest language. People are making millions with PHP. The end user doesn't care and tbh the ecosystem is awesome
> also can you believe it that with Node, the script is also the server???
That is how most modern web systems operate. It's very rarely a problem, because decent error handling (built in to most frameworks) limits the scope of these sorts of issues to a single request. IIRC, all of the major Node.js HTTP frameworks will catch exceptions for you and respond with a generic 500; I'm not sure what sort of system you had where your errors were bubbling up further.
> Without steps like the big improvements in PHP 7 and laravel, PHP could potentially already be irrelevant today.
So what? What's wrong with PHP becoming irrelevant? Surely nobody would complain that ColdFusion is finally irrelevant. People should focus their time and energy on better solutions than PHP or ColdFusion.
> People should focus their time and energy on better solutions than PHP or ColdFusion.
Yes they should, but none of the 'solutions' are actually much better. We should all just accept the cold, hard reality that the web was a huge mistake and never should have been created. Nothing good has come from the web. Personally I was much happier with usenet, ftp, and gopher.
I went from a WP/Laravel dev to .NET Framework and now .NET 5+. For me PHP has always suffered from two primary camps: ancient codebases that people don't dare touch, and poor tooling.
The former came mostly from the PHP camp. The lack of OOP where it was pretty desperately needed was unproductive at best, and at worst yielded a codebase that was so unmaintainable we had to double any time estimates for backend work.
For tooling Laravel, at least the last time I touched it, was pretty good with its scaffolding. Relying on Composer was also very welcome. Using IDEs like PhpStorm was pretty good, but took a lot of configuration.
The one thing that really burned me, however, was the amount of effort it took to get a debugger actually working. I am certain the climate is better now, but at the time almost no emphasis was put on actually using a debugger for development. You could get Xdebug running, but you have to know how to configure your local dev hosting environment properly. If you used a prebuilt package like your WAMPs or XAMPPs or whatever you, you got 90% there, but it's so bloated and didn't reflect your production environments. Vagrant was great... if you spent the time to configure your Vagrantfile with a lot of testing.
These days it takes about 30 minutes to reinstall Windows, install VS, clone my project, hit the run button and I'm off to the races. Is everything frictionless? No, of course not, but I can get to actually building my application without pulling my hair out.
I've been working with PHP for years, and to this day, I struggle to make xdebug work. I don't think it's a genuinely good debugger, which is something that PHP sorely lacks and is a negative aspect of the language.
At this point it makes the language/platform a complete non-starter for me. var_dump or echo or print is just not proper debugging. Especially once you level up your debugger skills and utilize more of the functionality rather than just setting basic breakpoints.
Like any programming language, encourage others to produce their own rather then just dumping "Use Symphony" "Use Flask" "Use Angler" "Use React".
This goes for all programming langs, the approach of "I know, lets use xFramework!" is flawed -- you end up with a generic X-lang website which caps your creativity because your locked in to using a framework based upon decisions of the developer. You add your stuff to it, dev updates the framework and you find out your stuff is broken because of some change. Frameworks restrict.
If people started to code their own like back in the day of PHPNuke, PHPCms, e107, PHPBB.. -- these languages wouldn't die. Not to add that the ecosystems of these frameworks are so fragile you end up with a convoluted mess where your stuck with the paradigm of the framework rather than your own design. This adds more further complication where your forced to abandon later on in the game or continue to be sucker punched because you want Z function, which won't be pushed in to the framework. You then create your own Z function but this adds overhead because any future update to the framework has potential of breaking your own function.
I'm an advocate to stop using frameworks. As a black smith does in making a hammer to smeld a tool to create an object. All takes time and effort, skills to develop. But when you do, the satisifaction is so worth it. Creating nothing is something; then from nothing creating something is an amazing feel. The wisdom, knowledge, hackery is far and beyond, you grow as a person. You end making something unique, something that no-one has ever made before. You have your own product.
Using a framework is skipping that step and using what someone else has created rather then your own.
Yes, controversial, you should be reinventing the wheel. Because if your not, your stuck with a pre-defined wheel where you are forced down a path of restrictions. Granted exceptions can be made if it's for corporate bandwagon but where's the individually of coding gone?
Some folks will never come to it, some folks will stick with it (like me).
Language is language. The value prop for most orgs using tech is the ecosystem. The PHP ecosystem is large, and has a lot of good quality stuff available. Building on laravel or symfony, or using products and services built around those, can be a big advantage over some other tech.
There are always examples and counter-examples, and usually a decision will come down to "you should use what a team is already skilled in". That's the pragmatic answer. You have a team of .net folks... don't jump to express or flask or laravel because of some benchmark or neat article or resume-driven-development. Stay in the .net world, and use what you know. That has to be balanced with "what you know may go away, so be ready to learn new things". Maintaining a balance, both for yourself, as well as the tech in your organizations, is something to regularly be aware of.
I love PHP. I like web stuff overall. Over the last... 30 years of software dev, what I've noticed is that the really useful/good ideas tend to get implemented in various languages if they're useful. The sign of a useful library can often be that there's multiple implementations of it. We saw a productized "web mvc" launch rails, and we then saw a dozen variations in other languages take the essential parts, implement them, and good ideas have flown between various tech camps for years since.
There are counterpoints to that. A colleague is doing some work in SciPy, and there doesn't seem to be an equivalent outside python. In PHP, we have FlySystem, and I've not yet seen an equivalent outside PHP. I've seen some attempts, but they tend to have one or two adapters, and that's it.
Overall, language diffs are often/mostly personal preferences. Your project or business isn't failing because your language of choice can't connect to a database quickly enough, or that you can't write data to filesystem, or whatever. But if you've spent X years with tech Y, you will likely be faster than learning something new (and learning the idiomatic methods of that new tech). Figuring out when to dig deeper, and when to move on... again - no single choice on that.
I may have shared it before, but I saw a company moving new dev away from PHP, and moved to a combination of python and node. "It's so much easier to hire people!" But... they were largely hiring jr and mid level people, and they were doing greenfield redevelopment of some of the PHP stuff. And... they'd attempted a rebuild of the PHP stuff once, but made the same mistake as the first time; primarily one person, working on their own, often offsite, not interacting with other people.
Moving to python/node, they hired more/cheaper people, and the rewriting team required everyone to work together. The languages were pointed to as the reason behind some of the early success, but it was far more the processes around the development that provided the success. With enough people, forced to write cleaner code the whole group can understand, as well as requiring tests and documentation... yes, the outcome is going to be better than requiring one person to build a lot of stuff on their own, without providing adequate time for testing, documentation, or collaboration with others.
Likely most of us have come across enough bad JS/Python/Perl/PHP/Java/C#/etc to understand the quality of the code is only tangentially related to the language, and far more about the processes and expectations set around the development.
New languages are hopefully made taking into account all the lessons learned from previous mistakes older languages made. Old languages can't change too much or they just become hell to upgrade, so they can't compete with the newer ones.
I don't think there's much of a problem with this.
But I will still setup a wordpress if I need a quick site.
The world that PHP grew up in has changed. The language and community have matured, and in the process PHP has lost most of its competitive advantage: low barrier to entry.
It used to be:
* Moving from static HTML to dynamic server code was a matter of changing file extension and adding PHP tags.
* Many shared hosting services supported PHP.
* Deploying was a matter of copying files to the server.
Projects that started from HTML + PHP tags grew and became unmaintainable messes. The PHP community learned from this and evolved in a different direction. You can still _write_ PHP code in the old way, but it's strongly discouraged and (rightfully) seen as a bad practice. You don't even use PHP as a templating language anymore. Symfony and Laravel have their own templating languages that dynamically compile to PHP.
Modern PHP code looks very much like Java or C# -- classes, OO design patterns, and so on. Except in most ways, it's worse than Java or C#. Why would anyone start a new project in PHP?
Deploy models have also changed. You're usually not copying files to servers, but deploying Docker images or other formats. PHP has no particular advantage in this new world.
If PHP wants to turn things around, it needs to figure out what makes it unique or better than other languages. Right now, there's really nothing.
That can work for a while but it doesn’t attract new developers, and it tends to have legacy projects be replaced outright with new ones in better languages.
That’s roughly what I was thinking, yes. There’s still a certain appeal to the easy install process but the gap is a lot lower now, the classic PHP way famously lead to security issues, and there’s a vicious flip where once you need to customize anything it goes from easier to harder than the average containerized Node/Python deployment since you need to learn how to run things like FPM rather than just installing a web server package. That also shows up with Composer - the standard library is big but once you need something else, the experience is worse than NPM or PyPI.
The fatal flaw in my opinion was not taking the language itself more seriously 20 years ago. The culture of laxness around things like type coercion, ignoring errors by default, being inconsistent about positional arguments and typing or nomenclature, etc. is so deeply ingrained that major improvement are much harder and will likely require advanced automated tooling. I left the community in the mid-2000s after getting burned out by the endless stream of security and correctness bugs caused by the language and culture – my favorite was the time a detailed bug report for functionality not matching the documentation was WONTFIXed since it was working as the core developers intended & they didn’t feel like updating the docs – but having had the misfortune of being involved with a PHP project again, the only big improvement I can think of was that register_globals isn’t the default. You still routinely see bugs caused by e.g. inconsistent array function parameter ordering causing errors which are silently suppressed despite our configuration having logging enabled for that class of error and the built-in linter won’t report. There was no reason to waste time on that in 2003, much less 2023.
I actually want a more refined version, with better ( or different ) syntax of old PHP.
And I really like you touch on low barrier to entry. Right now, in my likely controversial opinion, modern Web Dev is a huge pile of excess complexity.
The web has always been inherently complex, so it is only logical that frameworks for building things on the web have evolved to tackle all the possible complexity. Of course also the introduction of handheld devices and duplex multimedia features has made the web more complex, but mostly we just didn’t care 20 years ago, because we could get away with less. Now, more and more things are exposed to us every day, requiring us to grok it all to be able to make day-to-day decisions.
No wonder so many people turn to magical thinking, cargo cult coding or Uncle Bob -like messiahs.
To be honest apacha/nginx + php with laravel is probably few of the most stable web serves I've build. IMO it's still a lot lighter and easier then Java or C#. But yeah the old script kiddie days were great. And I do thing we should encourage users more to be more wild for small projects and just build something without a framework.
I think one potential improvement for PHP is to make PHP templating usable again. This is something that could have a low cost of implementation but a big win.
Example on improvements
1) auto-escape output - one of the biggest reason not to use PHP for templating is that you need to manually escape your strings to avoid XSS, whereas a dedicated templating library can do this for you. This could be done with a either a special opening and closing tag or let you register a tag hook.
2) today you can use the alternative syntax for if, while, for, foreach, and switch
This could be expanded for match expression, closures, and other block expressions.
3) custom HTML tag support, register a HTML tag like <my-form> and implement it thru an API, perhaps a class that implements an interface. And now you can do much better reusable components that can automatically close them selves instead of multiple calls.
In the first example you need to always match one function call with another function call ( manual work), in the latter example you HTML just needs to be valid, which many editors can detect for you.
And it would be easy to share these custom components on github with composer.
Every time someone says there’s really nothing that stands about php I roll my eyes. Php usually competes with JavaScript and python, all three being dynamic languages.
First of all, php is faster than python, and ruby and probably most dynamic languages except JavaScript.
So in terms of performance, modern php is ahead of the other languages and it scales well.
Regarding features, php has the best support for classes and types out of the three languages. So if you want to design a classic oo system, php has the best features language-wise.
Php also has a great community (good ides, good package manager, good open source libraries and frameworks).
What do other languages offer that php doesn’t have?
Meh, at this point it doesn't matter. There's so much (bad) php code out there that needs to be maintained, any person who learns to write good php has a job for life.
But I've always said that PHP's popularity was due to its availability on free hosting providers. However nowadays, you can get free hosting for a plethora of languages. So more competition, and also there are so many more languages that are competing for the backend nowadays.
It's because PHP isn't simple anymore. It requires an IDE, it's likely using a framework (at least Laravel seems relatively sanely designed), and everyone wants to make it contain all the features (and most importantly syntaxes) of all their favorite other languages.
If you're using an IDE already pretty much any language could be the same.
I like that PHP is not popular and looked down upon by the masses. There is so much less drama in the communities, there isn't a new resume driven framework made every other week, no one is try to spike extensions with malware, no real build system, so much less bullshit. Its like everyone one who uses PHP is to busy making stuff to be stirring drama online while the PHP core has been steadily getting better for the past few years.
It’s super cozy and honestly I don’t want it to get popular again so it can remain drama free and cozy.
I'd hate to see the other communities then! I think of PHP communities as full of drama, whether that's fads and dogmatism (which usually changes every 3-5 years) or people lacking interpersonal skills and unable to keep conversations civil.
Having converted a couple of PHP projects to modern languages and maintained way more than i care to admit:
Its not going anywhere. Or at least in europe its not.
Symfony et al have matured enough so they are usuable for allmost everything web related and if you dont plan to be the next google homepage, it will carry you VERY far.
Is it pretty? No. Is it efficient? No. But you will be able to find 10 coders for the price of 4, that will have your project iterate until you need something bigger and better. If you do not hate your staff, by then they can easily pick up golang and convert into microservices, taking it down piece by piece and making the parts more efficient that need it.
There is no structure, OO was an after thought, meta-programming an after thought., unit testing, testing utilities and frameworks an afterthought, their best Web-framework Laravel is a clone of Rails, No original good ideas in the PHP Community and thats the problem. The reason is PHP is a poor clone of Perl.
I was with you until the end. Originally doesn’t mean shit. Who cares if Laravel is a Rails clone? For the record, I have no idea if it is, let alone if it is beyond the degree that plenty of other things are “Rails clones”. And this is ignoring the fact that Rails had been inspired plenty by other projects throughout its lifetime, as it should.
I’m interested in using the right tool for the job, not getting caught up in weird inside baseball attribution wars. IMO, PHP is often not the best tool because it’s a shitty language. If it has a “Rails clone”, that makes it better, not worse.
It is a clone of RoR. Pretty much all open source projects take inspiration from other projects. Ironically, there’s not a single good clone of Laravel (or RoR) in node. Wonder why... (sometimes the language and it’s features do matter apparently (and yes I’m being sarcastic))
Are you serious? Jsx was first implemented in php by Facebook. One of the most popular features of modern JavaScript was original designed (and implemented) in php.
165 comments
[ 2.5 ms ] story [ 132 ms ] threadMaybe PHP can be made better, but it would need some radical changes and then the question is that if it’s worth the effort and maybe to pick up some of the new tools instead.
What's the JS FOSS equivalent of ProcessWire as a CMF + CMS?
What's the JS equivalent to e.g. DreamHost and other drag + drop hosts?
(Legitimately curious, and I'm mainly inquiring after equivalents-for...better-thans would definitely be interesting)
Those people just use drop-in tools now which are better than custom applications for a large portion of standard use cases.
It doesn't need to even look like index.php, just needs to be as convenient, ideally?
Drop-in tools? Examples? I was using PHP drop-in tools back in 2004 but I'm not sure if that's what you mean.
Modern php code uses Frameworks, Package mangers, opcode caching, and application servers. It’s just that other languages don’t carry all the cruft php has in its heritage…
Back when I was building applications in PHP it was all frameworks. package managers, op code caching, etc. But I no longer do PHP development but for my own personal websites I still use PHP but in that most minimal form.
So where is the hyper-simple JS equivalent for that class of non-enterprise projects, is what I wonder...the enterprise stuff has always been heavy and loads projects down with maintenance debt.
I actually like using a reliable package manager, a wide ecosystem of good packages, and modern language features. There is nothing "heavy" about modern PHP, unless you want it to.
How do these change the way you can deploy PHP files by simply uploading them?
For frameworks, all you do is run a single command to install.
If you mean JS package managers, that's agnostic to what language you use.
Opcode caching doesn't require anything special from deployment point of view and I don't see a need for app server for PHP.
Once you start getting into zero-downtime deployments, you'll quickly see the need for both application servers like Swoole or RoadRunner, as well as strategies that don't leave requests in the air with half the code from the old version and the other half with the new one.
Let HackerNews hobby programmers snark all they want, those are very real problems with very real solutions.
And then again, you’ll end up wondering why your servers should waste cycles upon cycles for executing the same bootstrap code over and over again, if they could instead only do that once, keep the app in memory, and only execute the request handling code… and just like that, you’ll end up with Octane, or Swoole, or what-have-you.
The tendency to have a npm package for everything is overwhelming because you end up with choice paralysis and risk on picking "Oh, you picked CSV-to-array library #823, it's the buggy/insecure/unmaintained one."
… in your echo chamber. I know first hand of multiple very large corps doing that (one of them being a bank and this is their payment api) and very many smaller shops. Sure, we recommend against it, but saying it’s decades ago like that is nonsense; many people do this because it’s convenient.
> just install 10 insecure npm packages that each install another 10 npm packages
I still don't understand why companies are fine with this.
At my last job, even principal and staff level developers needed every Windows or Mac application install vetted by IT. We had real time system monitoring on all employee workstations that ate up half the RAM and CPU resources and constantly kicked us off the VPN for even the slightest quirk (including the CPU redlining due to scanning).
But npm dependencies? Nothing. Install whatever you want and push it to production.
This is an S&P 500 company that deals with tons of PII.
I'm not saying this is good, but the reality with these company-internal restrictions is, that the most productive people find ways around them and are rewarded for it.
There is a HUGE advantage to using the same language in the browser and on the server, and PHP isn't ever going to displace JavaScript in the browser. So JavaScript it is. That ship sailed a LONG time ago.
I much prefer not having to write JavaScript everywhere, not every problem is a nail and not every solution requires a hammer.
You can simply compile your PHP code to wasm with emscripten, and then run it in the browser. Pretty straightforward. No more switching gears.
And in what concerns validation, it can be automated on most frameworks, which has to be done on server side anyway due to security concerns.
When people get what is peanuts in local currency of the owner company, whatever they are using doesn't matter and most sweet shops are experts in everything.
I can also tell that at the level I work on, salaries are the same regardless of FE, BE, DevOps, ...., specially because no one has a single role.
The point is it takes fewer people (or even the same person) to write less code (instead of writing everything twice, then trying to keep them in sync forever).
There's a fascinating deep discussion about SveltKit and other frameworks here:
Reacting To Web Hot Takes from Rich Harris - SVELTE STUFF
https://www.youtube.com/watch?v=JGuUY7dZhWs
Node typically IS the server. So, you could install express and have a simple web server listening on a port and serving up html or json in about 5 lines of code. Unlike PHP Node is not, in itself, a templating language. So if you want to render HTML pages you'd also need to install something like EJS, but generally node servers are just serving up JSON API, and your frontend would be some frontend framework (React, angular, vue). Although all of that is trending back the other way with NextJS the old is new again and server-side rendering is the hotness again.
Another option is to use a framework like NestJS. With that you do
For easy deploy. That was kinda Heroku's thing. You just "git push" a node project and it magically knows how to deploy it, but Heroku got bought by Sales Force and murdered from my understanding. There are a lot of alternatives though. AWS, Azure, Google, CloudFlare, Digital Ocean, etc, etc all have similar offerings where you just push a node project to git and it deploys automagically.Alternatively you can use AWS Lambda / Azure functions (or a dozen other "serverless" solutions) and you can just drop js files (functions) and they run on demand.
For a ProcessWire alternative there are a ton of options. A few I've seen are: Ghost, ButterCMS, Strapi
> AWS, Azure, Google, CloudFlare, Digital Ocean, etc
I'm always curious to know if there are more casual options in this space, for non-earthshaking projects. Maybe more like how DO was at the beginning?
Render.com, Fly.io, northflank. And I actually like AWS lambdas, so great option for me is SST.dev, which wraps AWS CDK, and provides an actual live development workflow with actual AWS resources.
My favorite way to do this is to add a custom script to package.json like:
"start": "pm2 start index.js --name myapp --watch"
Any file change will reload the application and if it crashes it will be restarted. So just scp/rsync files if that's your desired workflow.
In my experience, it's far easier and faster than setting up nginx, apache, fpm, etc, etc.
The tooling around languages matters much more.
C++ isn't still popular because it's the best language.
Only real reason I'd always pick PHP over JS is not because I love PHP, but because Laravel is better than any node framework.
They pick JS because they know the language best and are more productive in it than in Laravel. There is nothing Laravel can do about it - being best is not going to change the direction, because the limiting factor is the knowledge of programming languages of most of developers.
There are HUGE advantages and efficiencies to using the same language in the browser and the server.
Most developers are (rightfully) lazy and simply don't want to learn and juggle two different languages in two different places, when they can use simply one language everywhere.
For example, when switching between PHP and JavaScript, you have to remember that the ?: ternary conditional operator in PHP has idiotic left-associativity, so you have to use extra parenthesis to disambiguate it, while the identical looking ?: ternary operator in JavaScript and all other languages has sane right-associativity.
"I'm not a real programmer. I throw together things until it works then I move on. The real programmers will say Yeah it works but you're leaking memory everywhere. Perhaps we should fix that. I'll just restart Apache every 10 requests." -Rasmus Lerdorf
"I don't know how to stop it, there was never any intent to write a programming language [...] I have absolutely no idea how to write a programming language, I just kept adding the next logical step on the way." -Rasmus Lerdorf
"We have things like protected properties. We have abstract methods. We have all this stuff that your computer science teacher told you you should be using. I don't care about this crap at all." -Rasmus Lerdorf
I don't find it inconvenient to write PHP or JS syntax, it's completely trivial for a professional.
"We have things like protected properties. We have abstract methods. We have all this stuff that your computer science teacher told you you should be using. I don't care about this crap at all." -Rasmus Lerdorf
"There are people who actually like programming. I don't understand why they like programming." -Rasmus Lerdorf
"I'm not a real programmer. I throw together things until it works then I move on. The real programmers will say "Yeah it works but you're leaking memory everywhere. Perhaps we should fix that." I’ll just restart Apache every 10 requests." -Rasmus Lerdorf
"I don't know how to stop it, there was never any intent to write a programming language [...] I have absolutely no idea how to write a programming language, I just kept adding the next logical step on the way." -Rasmus Lerdorf
"Using these toolkits is like trying to make a bookshelf out of mashed potatoes." -Jamie Zawinski
"I used to think that PHP was the biggest, stinkiest dump that the computer industry had taken on my life in a decade. Then I started needing to do things that could only be accomplished in AppleScript." -Jamie Zawinski
"From what I've seen, PHP isn't so much a language as a random collection of arbitrary stuff, a virtual explosion at the keyword and function factory. Bear in mind this is coming from a guy who was weaned on BASIC, a language that gets about as much respect as Rodney Dangerfield. So I am not unfamiliar with the genre." -Jeff Atwood
https://blog.codinghorror.com/the-php-singularity/
On the other hand, Anders Hejlsberg is a highly skilled, careful, conscientious, experienced professional programming language designer, who actually knows what he's doing, and LIKES programming.
And as a professional programmer who's been writing lots of code in many languages since the early 1980's, I much prefer and enjoy using his well designed IDEs and programming languages like Turbo Pascal, Delphi, C#, and TypeScript, to carelessly hacked together fractals of bad design like PHP.
PHP: a fractal of bad design:
https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/
And you're still totally missing the point about the advantages of using one programming language on both the client an server side, sharing libraries, data, APIs, mental energy, and effort.
If you were really a professional programmer, you wouldn't be stuck in a rut using and apologizing for PHP, because you would be capable of learning and using many other vastly superior and more powerful programming languages and tools than PHP, and you wouldn't have to waste your time and mental effort rationalizing and making excuses, remembering to avoid so many unforced foot guns and idiotic bad design fractals, and carefully and defensively working around all of its flaws, while getting "yelled at by your IDE" all the time, instead of actually spending your finite time and energy solving problems.
You've got be more flexible than this, come on.
Bill Joy’s Law: 2^(Year-1984) Million Instructions per Second
https://donhopkins.medium.com/bill-joys-law-2-year-1984-mill...
"The peak computer speed doubles each year and thus is given by a simple function of time. Specifically, S = 2^(Year-1984), in which S is the peak computer speed attained during each year, expressed in MIPS." -Wikipedia, Joy’s law (computing)
"C++++-= is the new language that is a little more than C++ and a lot less." -Bill Joy
"You can't prove anything about a program written in C or FORTRAN. C is PEEK and POKE with syntactic sugar." -Bill Joy
"You can drive a car by looking in the rear view mirror as long as nothing is ahead of you. Not enough software professionals are engaged in forward thinking." -Bill Joy
“Java is C++ without the guns, knives, and clubs.” -James Gosling
A Conversation with Language Creators: Guido, James, Anders and Larry [video]
https://news.ycombinator.com/item?id=19568378
https://www.youtube.com/watch?v=csL8DLXGNlU
"My favorite is always the billion dollar mistake of having null in the language. And since JavaScript has both null and undefined, it's the two billion dollar mistake." -Anders Hejlsberg
"It is by far the most problematic part of language design. And it's a single value that -- ha ha ha ha -- that if only that wasn't there, imagine all the problems we wouldn't have, right? If type systems were designed that way. And some type systems are, and some type systems are getting there, but boy, trying to retrofit that on top of a type system that has null in the first place is quite an undertaking." -Anders Hejlsberg
Andrew Hejlsberg:
>Maybe I'll just add, with language design, you know one of the things that's interesting, you look at all of us old geezers sitting up here, and we're proof positive that languages move slowly.
>A lot of people make the mistake of thinking that languages move at the same speed as hardware or all of the other technologies that we live with.
>But languages are much more like math and much more like the human brain, and they all have evolved slowly. And we're still programming in languages that were invented 50 years ago. All the the principles of functional programming were though of more than 50 years ago.
>I do think one of the things that is luckily happening is that, like as Larry says, everyone's borrowing from everyone, languages are becoming more multi-paradigm.
>I think it's wrong to talk about "Oh, I only like object oriented programming languages, or I only like imperative programming, or functional programming".
>It's important to look at where is the research, and where is the new thinking, and where are new paradigms that are interesting, and then try to incorporate them, but do so tastefully in a sense, and work them into whatever is there already.
>And I think we're all learning a lot from functional programming languages these days. I certainly feel like I am. Because a lot of interesting research has happened there. But functional programming is imperfect. And no one writes pure functional programs. I mean, because they don't exist.
>It's all about how can you tastefully sneak in mutation in ways that you can better reason about. As opposed to mutation and free threading for everyone. And that's like just a recipe for disaster.
"I have a feature that I am sort of jealous of because it's appearing in more and more other languages: pattern matching. And I cannot come up wit...
"From my perspective, the point of all these "PHP is broken" rants is not just to complain, but to help educate and potentially warn off new coders starting new codebases. Some fine, even historic work has been done in PHP despite the madness, unquestionably. But now we need to work together to fix what is broken. The best way to fix the PHP problem at this point is to make the alternatives so outstanding that the choice of the better hammer becomes obvious." -Jeff Atwood
https://blog.codinghorror.com/the-php-singularity/
Leaning hard into the IDE (or ChatGPT these days) because your language design is flawed is a hella/totally stereotypical "West Coast" thing to do, as described in "Evolution of Lisp", "Worse is Better", and "History of T", and exemplified by Interlisp and Warren Teitelman's "pervasive philosophy of user interface design" and implementation of "DWIM".
https://en.wikipedia.org/wiki/DWIM
https://www.techfak.uni-bielefeld.de/~joern/jargon/DWIM.HTML
https://escholarship.org/uc/item/6492j904
If your language isn't terribly designed, then your IDE doesn't have to be such a complex non-deterministic Rube Goldberg machine, papering over the languages flaws, haphazardly guessing about your intent, "yelling at you" all the time about potential foot-guns and misunderstandings.
As you might guess, I'm firmly in the "East Coast" MacLisp / Emacs camp, because that's what I learned to program in the 80's. I can't stand most IDEs (except for the original Lisp Machines, and Emacs of course), especially when they keep popping up hyperactive completion menus that steal the keyboard input focus and spew paragraphs of unexpected boilerplate diarrhea into my buffer whenever I dare to type ahead quickly and hit return.
But my point is that you can have and should demand the best of both coasts, unless you start off with a Shitty West Coast Programming Language or a Shitty East Coast IDE.
(Of course those philosophies are no longer bound to the geographical coasts they're named after, that's just how those papers describe their origin.)
Jeff Atwood's point an my point is that we should demand both well designed programming languages AND well designed IDEs, not make excuses for and paper over the flaws of shitty ones.
There are historic existence proofs, like Lisp Machines and Smalltalk, and we should be able to do much better now, instead of getting stuck in the past with Lisp or PHP.
I mentioned the East/West Coast dichotomy in the discussion about the conversation between Guido, James, Anders and Larry:
https://news.ycombinator.com/item?id=19568860
>DonHopkins on April 4, 2019 | parent | context | favorite | on: A Conversation with Language Creators: Guido, Jame...
>Anders Hejlsberg also made the point that types are documentation. Programming language design is user interface design because programmers are programming language users.
>"East Coast" MacLisp tended to solve problems at a linguistic level that you could hack with text editors like Emacs, while "West Cost" Interlisp-D tended to solve the same problems with tooling like WYSIWYG DWIM IDEs.
>But if you start with a well designed linguistically sound language (Perl, ...
Also, server side JS is an absolute hard no for many, many server side devs who became server side devs after suffering with JS as full stack devs.
If ChatGPT is already perfectly solving all of your programming problems, then you should learn a lot more about programing, design, architecture, and security, so you can take on more challenging projects, and actually design decent APIs and architectures, instead of just paint-by-number monkey coding, and produce better more thoughtful designs and code than an LLM, because your job is already obsolete.
https://blog.codinghorror.com/the-php-singularity/
There is no app server or MVC to worry about. Every page is a template.
I find php easy to write, i can get an API running with a few lines of code without any library, and I find it very easy to deploy.
I recognize visual studio isn't required, but in the wild, the vast majority of C# devs I work with never leave VS.
The author links to the person thinking that HypeScript is a good name. He says:
"The name HypeScript sounds like a logical name for me, it pays its respect to the name PHP (PHP: Hypertext Preprocessor) as well."
That would be like suggesting that IBM rebrand itself "BizCompany" to pay respect to its own name (?)
Edit: Wikipedia says "PHP was originally an abbreviation of Personal Home Page, but it now stands for the recursive initialism PHP: Hypertext Preprocessor."
Celebrate.
It kinda says it all...
https://w3techs.com/technologies/history_overview/programmin...
1) First, understand that one audience matters particularly for programming language popularity, and that is people who are starting their careers. If you learn a language and use it for a few years, it tends to be a language you continue to use throughout your careers.
Here, we have no data. But I can tell you as someone who works with a lot of early stage startups and 20-somethings who are diving headfirst into programming for their startups for the first time, the language of choice is Python, followed by Javascript of some kind.
I have a long history with PHP and dearly love it as a language, but the concern I have is that it's not getting picked up like it was. Still love using it, and boy is Laravel productive for a small team.
That said, this is anecdotal, and I don't have any data here as the programming language surveys are always so broad they don't really have this kind of segmentation to spot early trends. Curious what others are seeing however...
2) Second, as chinabot pointed out, in the short term, AI is likely to supplement the work of programmers, making certain tasks faster and more efficient. However, as AI becomes more sophisticated and capable in the long term, it has the potential to largely replace a lot of programmers. In particular, AI's ability to automate the coding process means that many routine programming jobs may become unnecessary. While this shift may take some time, it's important for those in the programming industry to keep an eye on emerging AI technologies and be prepared for changes to come.
Does that imply that languages that are for working with AI would be the better programming languages to learn? Python, Julia, C++, Java and R are the current core languages in AI land. I don't think it matters in the short term, but the AI shift looks so big it could matter a lot in coming years.
IDK, doesn't look quite as cohesive and convincing as arguments after I wrote them down, but there are some pretty interesting points in here so I'll post it anyways to add to the discussion.
It is very fast for me to start, test & itterate.
I've also tried Node but idk sometimes it can hugg memory and even crash, which just never happened with PHP.
It is a little sad but I don't really care anymore because I am not doing client work anymore.
Edit: just to add that I also never really could stand promises in async execution. Such a headache.
Edit 2: also can you believe it that with Node, the script is also the server??? Who in their right mind thought this was a good idea? Like when the script crashed, it crashed the whole app for everyone.
That is how most modern web systems operate. It's very rarely a problem, because decent error handling (built in to most frameworks) limits the scope of these sorts of issues to a single request. IIRC, all of the major Node.js HTTP frameworks will catch exceptions for you and respond with a generic 500; I'm not sure what sort of system you had where your errors were bubbling up further.
So what? What's wrong with PHP becoming irrelevant? Surely nobody would complain that ColdFusion is finally irrelevant. People should focus their time and energy on better solutions than PHP or ColdFusion.
Yes they should, but none of the 'solutions' are actually much better. We should all just accept the cold, hard reality that the web was a huge mistake and never should have been created. Nothing good has come from the web. Personally I was much happier with usenet, ftp, and gopher.
The former came mostly from the PHP camp. The lack of OOP where it was pretty desperately needed was unproductive at best, and at worst yielded a codebase that was so unmaintainable we had to double any time estimates for backend work.
For tooling Laravel, at least the last time I touched it, was pretty good with its scaffolding. Relying on Composer was also very welcome. Using IDEs like PhpStorm was pretty good, but took a lot of configuration.
The one thing that really burned me, however, was the amount of effort it took to get a debugger actually working. I am certain the climate is better now, but at the time almost no emphasis was put on actually using a debugger for development. You could get Xdebug running, but you have to know how to configure your local dev hosting environment properly. If you used a prebuilt package like your WAMPs or XAMPPs or whatever you, you got 90% there, but it's so bloated and didn't reflect your production environments. Vagrant was great... if you spent the time to configure your Vagrantfile with a lot of testing.
These days it takes about 30 minutes to reinstall Windows, install VS, clone my project, hit the run button and I'm off to the races. Is everything frictionless? No, of course not, but I can get to actually building my application without pulling my hair out.
I would like the convenience of replacing one file somewhere and have the file be picked up by the server, similar to PHP.
I would also like to separate release and deploy and do an atomic load of the server.
I think there are Clojure projects to preload the JVM.
So when I upload the new version of the code, I can decide to release the feature when I choose to, rather than automatically at deployment time.
I think people use feature toggles to separate release and deploy.
This goes for all programming langs, the approach of "I know, lets use xFramework!" is flawed -- you end up with a generic X-lang website which caps your creativity because your locked in to using a framework based upon decisions of the developer. You add your stuff to it, dev updates the framework and you find out your stuff is broken because of some change. Frameworks restrict.
If people started to code their own like back in the day of PHPNuke, PHPCms, e107, PHPBB.. -- these languages wouldn't die. Not to add that the ecosystems of these frameworks are so fragile you end up with a convoluted mess where your stuck with the paradigm of the framework rather than your own design. This adds more further complication where your forced to abandon later on in the game or continue to be sucker punched because you want Z function, which won't be pushed in to the framework. You then create your own Z function but this adds overhead because any future update to the framework has potential of breaking your own function.
I'm an advocate to stop using frameworks. As a black smith does in making a hammer to smeld a tool to create an object. All takes time and effort, skills to develop. But when you do, the satisifaction is so worth it. Creating nothing is something; then from nothing creating something is an amazing feel. The wisdom, knowledge, hackery is far and beyond, you grow as a person. You end making something unique, something that no-one has ever made before. You have your own product.
Using a framework is skipping that step and using what someone else has created rather then your own.
Yes, controversial, you should be reinventing the wheel. Because if your not, your stuck with a pre-defined wheel where you are forced down a path of restrictions. Granted exceptions can be made if it's for corporate bandwagon but where's the individually of coding gone?
Language is language. The value prop for most orgs using tech is the ecosystem. The PHP ecosystem is large, and has a lot of good quality stuff available. Building on laravel or symfony, or using products and services built around those, can be a big advantage over some other tech.
There are always examples and counter-examples, and usually a decision will come down to "you should use what a team is already skilled in". That's the pragmatic answer. You have a team of .net folks... don't jump to express or flask or laravel because of some benchmark or neat article or resume-driven-development. Stay in the .net world, and use what you know. That has to be balanced with "what you know may go away, so be ready to learn new things". Maintaining a balance, both for yourself, as well as the tech in your organizations, is something to regularly be aware of.
I love PHP. I like web stuff overall. Over the last... 30 years of software dev, what I've noticed is that the really useful/good ideas tend to get implemented in various languages if they're useful. The sign of a useful library can often be that there's multiple implementations of it. We saw a productized "web mvc" launch rails, and we then saw a dozen variations in other languages take the essential parts, implement them, and good ideas have flown between various tech camps for years since.
There are counterpoints to that. A colleague is doing some work in SciPy, and there doesn't seem to be an equivalent outside python. In PHP, we have FlySystem, and I've not yet seen an equivalent outside PHP. I've seen some attempts, but they tend to have one or two adapters, and that's it.
Overall, language diffs are often/mostly personal preferences. Your project or business isn't failing because your language of choice can't connect to a database quickly enough, or that you can't write data to filesystem, or whatever. But if you've spent X years with tech Y, you will likely be faster than learning something new (and learning the idiomatic methods of that new tech). Figuring out when to dig deeper, and when to move on... again - no single choice on that.
I may have shared it before, but I saw a company moving new dev away from PHP, and moved to a combination of python and node. "It's so much easier to hire people!" But... they were largely hiring jr and mid level people, and they were doing greenfield redevelopment of some of the PHP stuff. And... they'd attempted a rebuild of the PHP stuff once, but made the same mistake as the first time; primarily one person, working on their own, often offsite, not interacting with other people.
Moving to python/node, they hired more/cheaper people, and the rewriting team required everyone to work together. The languages were pointed to as the reason behind some of the early success, but it was far more the processes around the development that provided the success. With enough people, forced to write cleaner code the whole group can understand, as well as requiring tests and documentation... yes, the outcome is going to be better than requiring one person to build a lot of stuff on their own, without providing adequate time for testing, documentation, or collaboration with others.
Likely most of us have come across enough bad JS/Python/Perl/PHP/Java/C#/etc to understand the quality of the code is only tangentially related to the language, and far more about the processes and expectations set around the development.
I don't think there's much of a problem with this.
But I will still setup a wordpress if I need a quick site.
It used to be:
Projects that started from HTML + PHP tags grew and became unmaintainable messes. The PHP community learned from this and evolved in a different direction. You can still _write_ PHP code in the old way, but it's strongly discouraged and (rightfully) seen as a bad practice. You don't even use PHP as a templating language anymore. Symfony and Laravel have their own templating languages that dynamically compile to PHP.Modern PHP code looks very much like Java or C# -- classes, OO design patterns, and so on. Except in most ways, it's worse than Java or C#. Why would anyone start a new project in PHP?
Deploy models have also changed. You're usually not copying files to servers, but deploying Docker images or other formats. PHP has no particular advantage in this new world.
If PHP wants to turn things around, it needs to figure out what makes it unique or better than other languages. Right now, there's really nothing.
There’s no niche that PHP needs to fill except for “a language for people who don’t want to move off of PHP.”
The fatal flaw in my opinion was not taking the language itself more seriously 20 years ago. The culture of laxness around things like type coercion, ignoring errors by default, being inconsistent about positional arguments and typing or nomenclature, etc. is so deeply ingrained that major improvement are much harder and will likely require advanced automated tooling. I left the community in the mid-2000s after getting burned out by the endless stream of security and correctness bugs caused by the language and culture – my favorite was the time a detailed bug report for functionality not matching the documentation was WONTFIXed since it was working as the core developers intended & they didn’t feel like updating the docs – but having had the misfortune of being involved with a PHP project again, the only big improvement I can think of was that register_globals isn’t the default. You still routinely see bugs caused by e.g. inconsistent array function parameter ordering causing errors which are silently suppressed despite our configuration having logging enabled for that class of error and the built-in linter won’t report. There was no reason to waste time on that in 2003, much less 2023.
And I really like you touch on low barrier to entry. Right now, in my likely controversial opinion, modern Web Dev is a huge pile of excess complexity.
No wonder so many people turn to magical thinking, cargo cult coding or Uncle Bob -like messiahs.
It's hassle free to host on a shared host and it'll be there forever
Example on improvements
1) auto-escape output - one of the biggest reason not to use PHP for templating is that you need to manually escape your strings to avoid XSS, whereas a dedicated templating library can do this for you. This could be done with a either a special opening and closing tag or let you register a tag hook.
2) today you can use the alternative syntax for if, while, for, foreach, and switch
https://www.php.net/manual/en/control-structures.alternative...
This could be expanded for match expression, closures, and other block expressions.
3) custom HTML tag support, register a HTML tag like <my-form> and implement it thru an API, perhaps a class that implements an interface. And now you can do much better reusable components that can automatically close them selves instead of multiple calls.
e.g instead of
you can do In the first example you need to always match one function call with another function call ( manual work), in the latter example you HTML just needs to be valid, which many editors can detect for you.And it would be easy to share these custom components on github with composer.
First of all, php is faster than python, and ruby and probably most dynamic languages except JavaScript.
So in terms of performance, modern php is ahead of the other languages and it scales well.
Regarding features, php has the best support for classes and types out of the three languages. So if you want to design a classic oo system, php has the best features language-wise.
Php also has a great community (good ides, good package manager, good open source libraries and frameworks).
What do other languages offer that php doesn’t have?
But I've always said that PHP's popularity was due to its availability on free hosting providers. However nowadays, you can get free hosting for a plethora of languages. So more competition, and also there are so many more languages that are competing for the backend nowadays.
If you're using an IDE already pretty much any language could be the same.
It’s super cozy and honestly I don’t want it to get popular again so it can remain drama free and cozy.
I'd hate to see the other communities then! I think of PHP communities as full of drama, whether that's fads and dogmatism (which usually changes every 3-5 years) or people lacking interpersonal skills and unable to keep conversations civil.
I settled for writing frumpy code at frumpy companies for years, but my life got better when I tried to chase after things a little more.
Speaking words of wisdom, PHP.
Its not going anywhere. Or at least in europe its not.
Symfony et al have matured enough so they are usuable for allmost everything web related and if you dont plan to be the next google homepage, it will carry you VERY far.
Is it pretty? No. Is it efficient? No. But you will be able to find 10 coders for the price of 4, that will have your project iterate until you need something bigger and better. If you do not hate your staff, by then they can easily pick up golang and convert into microservices, taking it down piece by piece and making the parts more efficient that need it.
I’m interested in using the right tool for the job, not getting caught up in weird inside baseball attribution wars. IMO, PHP is often not the best tool because it’s a shitty language. If it has a “Rails clone”, that makes it better, not worse.
"PHP is used by 77.5% of all the websites whose server-side programming language we know."
https://w3techs.com/technologies/details/pl-php