The stack of a major site could include words you haven't heard yet, prompting urgent studying. Or it could be a bunch of traditional stuff like here, implying a whole lot of new tech could be overhyped. If they can do it with PHP and MySQL, why not your project? :-)
I worked at the second largest adult content network about 10 years ago. They used the same stack mentioned in the article. The design philosophy was about simplicity and continuity above all. They didn't want to use newer technology because it's hard to find people to support it. They didn't even like you to use regular expressions when case statements could be used. Regex is too conceptually complicated.
If you can host and serve porn on a LAMP stack from a traditional bare metal server data center, the guy on the other end doesn't care as long as it's reliable.
I work at a large tech company now and it amazes me how terribly executed and unnecessarily complex most development efforts are. There was a very strong results-oriented culture at the adult media company.
It's funny how in 2020 PHP use is a sharply bimodal signal—it either means your tech leadership is clueless/absent/hopelessly-terrible, or they are among the few who've achieved true enlightenment.
PHP is a very robust, debugged, proven, workhorse language, with millions of pages of documentation, tens (probably hundreds) of thousands of seasoned developers, huge libraries and communities of support, decades of experience, strong, universal, server support, and is used on a lot of "big pipe" servers.
Like C++, it's not going anywhere, anytime soon; despite all the kvetching about it.
That said, I don't especially like the language, but I knew that I needed to use it, if I wanted to design an infrastructure system that I could throw over the wall to be taken over by a bunch of other people.
I was right.
There's that old urban myth about the fancy space pen, vs. the pencil.[0]
You can still (mostly) code in PHP4 style and ignore all the new cruft and syntactic sugar they added over the years. And you get the performance boost of 7.x for "free".
Yes, I suppose what really worries me about the "Modern PHP" movement how it looks down on anything that isn't Java-style OO. Procedural PHP is now considered to be some kind of unwashed Cinderella. I cringe when I look at a typical PSR-compliant page of PHP with its K&R braces, blank lines between each line of code and fanfold doc comments. You're lucky if you get more than a handful of lines of business logic on a screen.
I never learned Java until late in my career (when I learned up on Android). I started as an EE, and my programming has been primarily self-taught.
PHP is a kind of crappy OO language, but it is sufficient. I think Java is a better language, for OO. PHP 7+ is lot better than it was, before 5.
A lot of Java programmers came out of school, and started to create PHP chimeras. I feel as if that results in unnecessarily complex code. Things are complex enough, without applying UI-style MVC to server backend systems.
I wrote PHP for around twenty years, starting off procedural and mixed into HTML pages, to OO-based pure PHP systems.
I stopped a couple of years ago. This was my final PHP project[0][1]. It was sort of a "dissertation." No one is actually interested in using it, but it was developed in order to practice my architectural skills. It's a pretty intense system.
It's crazy how conservative most high-reliablity high-volume stuff is on the technical side. And yet, especially the porn industry, is quite on the fore front of other tech, like VR, DVD, VCR,...
They don't seem any different from other industries in this respect. A lot of banks still run on systems originally designed in the 60s. So they are conservative from an operations perspective. But most of the big ones have no issues pumping money into the latest financial fad, so they are pretty flexible from a product perspective.
Their content is relatively cheap to produce and it tends to be churned out at a high frequency. There's almost no industry out there that matches the frequency of content they produce, except maybe radio (and now YouTube). And with new technology, the limiting factor is almost always content creation.
So it makes sense that they'd put aside a few dollars buy some new equipment for some trend. Doing a VR shoot probably involves a new camera and a plugin for Premiere.
i truly believe that a lot of devs make stuff often much more difficult than necessary JUST for the sake of it.
reason is probably that the main product is boring af, so you need some distraction to keep it interesting :-)
> They didn't even like you to use regular expressions when case statements could be used.
I'm confused. How are those two related? Case statements can replace if statements and can be used for exhaustiveness checking. Regexes are for parsing strings.
All of the stuff you can do with regexes can be done with some hand written code. Since thst code often implements the FSM for the regex, it contains a fair share of case statements.
The benefit is that the regex library costs a lot in hidden complexity - debugging why a particular regex works slowly or eats lots of memory is hard. If a similar problem pops up in hand written code, you can use your standard profilers and other tools to see what's happening.
The corresponding FSM usually isn't too bad. I've personally never really used regexes that much in production code, but I guess I don't work with strings very often.
Well, I read Jeffrey Friedl's "Mastering Regular Expressions" two or three times since the 2nd edition was released and I can tell you there's no way anything more than a simple regex is going to be easier to grok when converted to some FSM, especially with look-behind or lazy operators and significant backtracking. I'm referring to the Perl/PCRE regular expression flavour which is the only variant that matters to me. Perl regexen are NFA so I'm not sure your assumptions about FSMs apply.
It's not always simple. Regexes have inherent complexity because the equivalent FSM is, in general case, nondeterministic. This implies it cannot always be easily simulated.
So you either drag this complexity into your code or dump it on the regex library. It's a trade-off.
I encountered one of these once. A user decided to enter this in the middle of their post:
------------------------------
It triggered catastrophic backtracking, and IIRC, 16 characters was right around where you could see noticeable delay, then at about 19 was when it ran so long it never returned.
I think the point was that even within the codebase, simplicity and reduced complexity was preferred over perhaps a "cleaner" or more advanced approach.
So managing a bunch of hard-coded code paths via a switch instead of using a regex to pattern-match.
It's less future-proof, but even an entry-level dev can reason about a switch statement and update it as needed.
This is exactly it. The nuances of regex patterns can be misconstrued. Obviously if the regex used for flow control cannot be sensibly translated to more traditional conditional statements, then they are permitted. Even in that case, the "simplest" regex was preferred.
Yeah, reading too much HN might make you think that the only way to write a scalable website is to write your backend in Rust, use Kubernetes, Cassandra w/ PostgreSQL, Kafka, and Hadoop, and TypeScript w/ Webpack and complex functions compiled to WASM.
The K8 cult annoys me most. When Kubernetes and Docker hit the scene YAGNI was the idiomatic response to any scaling scenario which involved less than a massive fleet of servers. Now every solo dev looking to launch his tiny Node app on AWS is expected to use Docker and Kubernetes. Utter madness.
Very true, which is why I, as a manager, ask senior devs during interviews why they made those choices and how they integrated and deployed the changes. In a lot of cases it turns out their flashy new tech choices were for one-off greenfield projects that were support systems and not primary production systems. I'm usually more interested in how they improved prod systems using the existing stack. This helps me figure out if they're into maintenance work or if they're only interested in tinkering with shiny new things. Both activities have their places on dev teams, but I take it consideration for the actual role I'm filling.
