Bad coding is infinitely worse than a “bad” language.
I don’t know how many of you are musicians, but many people are surprised to find that the tone quality of a guitar has way more to do with the person playing it than the way it was built.
Bad languages, more than anything else, frustrate your expectations and encourage developers to do things that are difficult to maintain. Sure, a great basketball player can dribble with gloves on his hands, but he’s making the task harder on himself, and anyone who’s less than great is less likely to be able to hold on to the ball at all in that case.
What do you mean "the type of strings"? In pretty much every programming language, String is one of the most fundamental types. There's no "different types of string".
(yes, this is a joke, a bad one at that. badum tish)
there's String, string, std::string, and the satanic *char. Just like there's Slinky, Super Slinky, Extra Slinky, Heavy, and Pro. Nickel-wound (ref counted), steel wound (raw array), and classical nylon (a fucking pointer).
lol, those would be raw pointers as well but at the asm level with registers. Joking aside, gut strings are extremely rare outside professionals. I’m not surprised to see it mentioned with this crowd. Cheers for tickling this music nerds interests.
Can confirm. judyrecords is built on a near framework-less monolith in PHP + 2 search servers. Searches complete within 100 milliseconds and SRPs return in less than 15 milliseconds on average. Runs a trimmed down version of CodeIgniter 2 (released in 2012) updated to run on PHP 8.2. Still got the CI 2 profiler.
Yes, I recently built a small PHP example project for educational purposes and I intentionally avoided all external dependencies for demonstrating how you would solve things without a framework or library. You can do almost everything you need with plain PHP without too much effort except a few exceptions that you shouldn't waste your time on, most of them are tooling however and not for the application itself, like unit testing, error tracking and logging, database migration, but for that you of course use libraries.
Sure, but framework-less PHP incentivizes poor architecture (hey we can do everything in 1 file to KISS x 100 endpoints = microservice hell). Requires an expert and disciplined engineer to execute well.
Sure you could, but it would take a much longer time and you'd miss lots of functionality. How long would it take you to build user registration / verification / password recovery / 2fa / sso / profile editing / spam registration prevention / etc. ? How long would it take instead to include some Laravel module which does all of that? If you're building a service with some purpose, do you really want to spend days writing the first option instead?
How many hours spent on battling Laravel to do what you want? How many hours spent on upgrading Laravel versions?
Framework solves a general problem, but we try to solve a specific problem, thus it will always be a mismatch, frameworks usually solves that with a combination of magic and opaque abstraction layers.
Frameworks works best for short running projects, long running projects tend to outgrow the framework.
That works for some things better then others. For example user management is hard to do as a library, because now you need to hook up all those actions / pass the data to them manually. Then make sure you handle all the headers correctly. Then handle the sessions/invalidation yourself. Potentially implement your custom authz as well because that's also happening throughout your app. There's still a lot of glue code that would be involved here - it may be worth trading it for the occasional Laravel upgrade.
Personally if I was "stepping up" from PHP and wasn't going to use something powerful (or didn't need all that power) I'd be stepping up into javascript and nextjs and stuff like that.
I was at RailsConf 2022 and it was packed, even considering the strict covid rules. There were lots of people there from teams transitioning from React+Go to Rails.