338
What are your programming hot takes?
(lemmy.ml)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 01 Sep 2023
338 points (100.0% liked)
Programming
17352 readers
249 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 1 year ago
MODERATORS
Pervert.
It's just that it's an ugly and weak language, overly verbose, and riddled with inconsistencies. There are few good things you can do in PHP without huge frameworks.
You're comparing to only JavaScript, have you worked with another language like python, ruby, lisp, rust? Maybe then you'd see what I mean.
By verbose I mean that mostly PHP lacks syntactic sugar, mostly it lacks powerful features of other languages. You can mostly write very simple procedural code.
Type hints and comprehensions as in Python, borrow checker, traits, code interface checking in Rust. Most functional features.
IDK; I just don't like anything about PHP and I have worked with it. It seems bad at every task.
I don't have issue with methods being 200 lines, as long as they have a singel concept and is easy to follow.
If the method does a long thing, the keep it long. I do a lot of data analysis and simulation, and so often people who came before had this urge to shorten methods, so we get:
Sometimes there's a place for that, like if
calculationcould be swapped for a different function, or ifcalculationis used all over the program. It's a pretty good clue that something is up though when the signatures are almost identical. Of course, that has just led to people writing:Hahaha this is great! All points are basically entirely obvious and common sense and then you hit us with that ridiculous statement about PHP. Outrageous!
Honestly, “it’s better than JavaScript” is a pretty low bar.
I don’t like PHP because I think the syntax is ugly and I’ve only used it on systems that are old and a pain to maintain, but I’ll also very freely admit that I have absolutely not written enough PHP to have an informed opinion on it as a language.
PHP grew "organically" out of a perl library. There was never a consistent plan/idea about the set of abstractions it provides, the type system, builtin functions etc.. Everything has been bolted on here and there, some additions good, some bad, some terrible pitfalls. A language with builtin operators that are basically unusable (comparison!) and where some functions return false when the input is invalid, is really fundamentally broken. I agree that many of the worst failures of PHP have been (kind of) fixed after PHP5 and that's nice for large existing PHP codebases (mediawiki, wordpress, nextcloud, typo3). But I just can't understand why one would start new projects in PHP in a world where so many very well designed and well thought through languages exist.
Edit: First sentence is misleading. Of course it wasn't a perl lib, but basically a thrown together bunch of functionality, unified into one package, so it can replace using various perl libraries. The syntax was also very inspired by perl.
Yes, JS is equally terrible! At least we can agree on that :-P
And I also understand that PHP (just like most technologies) can be very efficient to work with if you are used to it and know it very well.
If it doesn't fit on my screen it's too long.
This is a security thing. A descriptive error message is useful for troubleshooting, but an error message that is useful enough can also give away information about architecture (especially if the application uses remote resources). Instead, provide an error code and have the user contact support to look up what the error means, and support can walk the user through troubleshooting without revealing architecture info.
Another reason can be i18n/l10n: Instead of keeping translations for thousands of error messages, you just need to translate "An Error Has Occurred: {errnum}"
Those benefits both make sense, but are those really the original motivation for Microsoft designing the Blue Screen of Death this way? They sound more like retroactive justifications, especially since BSODs were around well before security and internationalization were common concerns.
PHP the language has become pretty nice, but I recently had to work with a PHP CMS deployment, and it was an absolute pain to do. PHP frameworks seem to still exist in a world where you manually upload code to a manually configured server running apache. Dockerizing the CMS (uses Symfony) is/was an absolute pain.