171–180 of 318 posts
Earlier quoted context omitted.
> Javascript is what PHP should be since day 1. ReasonML or ReScript is what JS should have been since day 1.
It's not fun sir. What's the point of those $$$ mark for variables ? Make no sense at all. Easy adoption for all levels of programmers is what make it work for enterprise applications now.
Syntax sugar is nice. It helps PHP sidestep the age-old criticism about its crappy API, although the crappy API is still there if you want to use it. What's really great about PHP these days is the development environment. Composer is a rock-solid package manager. Most frameworks and important libraries are gravitating toward shared standards defined by PSRs. Thanks to those shared standards, the APIs are stable and…
> There's no colors/faker/left-pad drama. Yet . Composer packages have the same attack surface as NPM packages, the only thing that is different is that there are (outside of frameworks like Drupal and Symfony) no automated post-install scripts that get executed during a "composer install". The fundamental difference is that lots of what is popular in the NPM world isn't needed in the Composer world at all due to PHP…
Earlier quoted context omitted.
PHP and Java are indeed superficially similar (this was claimed 20 years ago, too). You can't get rid of old stuff in the name of BC, but you often simply don't have to use that old stuff. For example, people hate on JavaScript (and PHP too I believe) for the semantics of their "==" operator, but it's a moot point since these languages have had "===" since many years.
If you are enough aware of the differences that you know you should use `===`, the difference becomes moot, because this is not the only unityped footgun on the language, and one of the easiest ones to deal with. The practical problem with `==` is for beginners, and the reason most people refer to it is because it showcases a very large and deep flaw of the language, not because of itself.
Every beginner knows that because all recent books literally say "don't use ==, use ===", modern IDEs will point it out for you and 1st code review feedback will point it out.
What usage of this moot point showcases for me is mostly author's blind bashing without real knowledge.
Earlier quoted context omitted.
> Why would I choose PHP when starting a greenfield project? Because you don't know better. If all you have is a hammer, everything looks like a nail. Ruby + Rails is miles ahead of PHP + Laravel. If you want more static typing (which I currently believe is a good thing) I really like Kotlin (+ KTor or + Javalin). If you are okay without OO and like static typing Haskell + IHP is pretty complete. If you are okay with…
You can write JavaScript via Typescript, and you now have one of the best and most popular languages there is (including sum types). There are still a lot of warts, but it’s actually a really nice language IMO.
Things are improving as more and more "batteries included" projects are launched, and it's better today than it was a year ago, so I'm happy about the positive change and I am optimistic about the future, but right now I can't begin to imagine labelling TypeScript as even close to being one of the "best" languages, because delivering software with it is a nightmare. TypeScript is great to write but hell to turn into JavaScript.
Is it just me or PHP's evolution is a bit "too little, too late" for an almost 30-years old language? PHP is not a likable language but it's probably not going away any time soon. Its concept of "one endpoint is one script" is one of its biggest killer features that no other language has been able to deploy in such an accessible manner. Well, Perl and old-style CGI aside, of course. That, and also the fact that it ma…
Its concept of "one endpoint is one script" is one of its biggest killer features Is that still a thing in PHP world? I recently ended up working on a 'modern' PHP project using Laravel and it was all routers and views and models and auto-generated scaffolding code, just like Rails and Django. There was no sign left of that 'old' approach.
Earlier quoted context omitted.
The big guys, who know what they're doing use PHP because it makes devops stupid simple. Throw it on the server, its ready. That's always been PHP's killer feature.
Is it? Last time I used PHP (around 5.x-7.x) it was exactly the other way around. For production you needed php-fpm, nginx, opcode cache... it was a nightmare compared with go or even java. Is it better now?
Earlier quoted context omitted.
If you are enough aware of the differences that you know you should use `===`, the difference becomes moot, because this is not the only unityped footgun on the language, and one of the easiest ones to deal with. The practical problem with `==` is for beginners, and the reason most people refer to it is because it showcases a very large and deep flaw of the language, not because of itself.
> If you are enough aware of the differences that you know you should use `===` Every beginner knows that because all recent books literally say "don't use ==, use ===", modern IDEs will point it out for you and 1st code review feedback will point it out. What usage of this moot point showcases for me is mostly author's blind bashing without real knowledge.
Earlier quoted context omitted.
> I'm curious what is the value proposition of the latest PHP version(s). I think more and more people have started to realise that typed languages make better, more reliable software. The incremental additions to PHP's type system are just a move towards this, I think and can be seen in other languages such as Typescript. I'm just not a fan of dynamically typed languages anymore, even for small scripts. > Why would…
I think that says more about your particular mental model of programming than about programming in general. In the couple of decades I’ve been coding, I’ve seen good use of both dynamically/weakly-typed and strongly typed languages. Sure— thinking you’re going to save time writing more complex applications by avoiding boilerplate is flatly wrong. However, if boilerplate would be a double-digit percentage of your code…
PHP is my go to language for building simple backends that store data as json in a file and synchronize access using flock(...). There are a ton of cheap hosting providers that support PHP and all you have do to is copy your files over and everything works. I love to focus my energy on building a great frontend with React or Vue.
You have any good simple examples of your backend? Sounds like what I've been attempting to explain to others. How many concurrent requests and what size of data can you run with a setup as described?