Every Oracle Pro*C application that I could find, I have rewritten as #/bin/php -f. Good riddance to bad rubbish.

I also just trashed an extremely repugnant PDF template processor, first with fpdf.org, then with tcpdf.org - far from perfect, but improvement a thousand fold.

Exaggerate, you say? Can I interest you in COBOL on my VAX (I'm not kidding)? Or perhaps (is this is too new-fangled) assembler under EXEC-8 on OS2200?

I do like the PHP solutions very much, and yes, I work in a museum.

It also launched many information security careers :)

Injecting strings from user input into generated HTML? Sure, to hell with checking if it contains script tags and/or onclick= attributes, or perform any kind of escaping alltogether for that matter.

Worse, automatically adding request variables to the global namespace, in an order that if input validation is implemented but naively/buggily there can be easy ways to bypass it.

this is the programmer's fault and responsibility

Unfortunately the low barrier for entry meant that many programmers hit the ground "running" with no knowledge of such issues, so ended up creating much insecure code simply by never knowing any better.

Not for a programming language calling itself portable Hypertext processor, no. In fact, it's bordering on criminally negligent.

PHP have htmlspecialchars() and parameterized queries since 2000.

1. XSS != SQL injection

2. Adding a bunch of bogus escaping routines isn't an excuse for an incredibly poorly conceived off language, or continuing using it in production in the presence of superior solutions.

In fact, I'd go so far as to say if you're selling PHP solutions/consulting in this century for apps managing ecommerce or any other kind of PII, you should demand your customer signs a liability waiver. If you can even disclaim liability for gross negligence in your jurisdiction, that is.

What should php do then? What's the alternative language that handles this better?

For traditional PHP apps wishing to continue SSR and server-side templating, integrate HTML-aware templating (PHP has always been half there considering embedded PHP is using SGML processing instructions; it "just" needs to offer additional, more sophisticated, injection-free SGML entity-based mechanisms).

For highly dynamical apps, consider porting to JavaScript on the client side, and use PHP only as a service backend language. That's what I understand newer PHP frameworks are doing; but this will only be attractive for migrating legacy PHP apps rather than bring new users.

I don't see the upside to the effort of porting to js. You still have all of the same pittfalls. Yes, you can build a DOM with 20x the code and 1/20th the performance ... or you can just call htmlspeciachars() in php. Yup, security is tedious and you need to stay on your toes.

When I developed in PHP, the first line of my code was usually renaming "htmlspecialchars" to "h". This significantly reduced the length of code and increased its legibility.

If someone proposed a conspiracy theory for why the rapid application development tools of the middle 1990s became extinct in reaction to plotting by corporate interests in perpetuating the value of consulting services and the high salaries of CS graduates, I would buy the hardback edition immediately. VB, Visual Age, Delhi, Genera on Tru64, RDB and RMS and DEC TM giving you schema less (noSQL to taste) wan -clustered ACID time series transactions programmable in BASIC, COBOL, FORTRAN C and DCL on any two of three architectures (VAX, Alpha and Itanium - currently available for running unchanged on x64 VMs) and the OS/2 subsystem bundled (plus the first free beer transaction manager NT provided working with CICS, a feature that I truly believed was capable of giving Microsoft the corporate game by itself) which provided a VBA front end to legacy systems alongside local OS/2 tools running atop the kernel thru W2K.. the day I in place upgraded my overloaded think pad in a hotel room in Köln, and I realised when Slashdot loaded in Netscape 7 that Microsoft couldn't get any respect for anything even as impressive as W2K truly was –

Edit : large part cut for brevity

I really should have composed what I just said, much better than I have done -/so I have cut the bulk from my first too enthusiastic version / I mean to describe how much you can get running with just BASIC language skills and, at least atop of VMS, and buying the right licenses, that answer is "anything almost anything that you can imagine from a power station to a stock exchange ". Stack Overflow and POF running tiny amounts of hardware under Windows Server aren't rare cases of the potential for leveraging commercial tools. If VMS is more palatable than Windows (and certainly I will not compare the two for TCO) and the Intel architecture pricing for RDB holds up I totally believe that SAAS on VMS can be a viable alternative platform capable of making a minor industry of positions for the experienced programming talent for whom ageing has become a invisible barrier to retirement or even employment and if that's possible, then there's right there the environment wherein a generation of younger engineering minds can both take respite from rat race technology change and learn from direct experience to write the reliable systems for replacing what I fear is a current batch of the most fragile infrastructure building in modern history.

edit : incidentally, I think the entry level salaries the FAANG group is paying is a coincidentally perfect match for the price for a consultant from IBM or whoever and I don't think this is a accident by any means, only it didn't seem to work out how the old big firms would have wanted things..

edit, again, mea - my conspiracy being IBM et.al killed the good development tools in hope for being able to bill for consultation only they didn't count on the ability for big tech competitors to dismantle entirely other industries to feed paying salaries at the level of consulting rates and monopolizing the talent in that way.

> why the rapid application development tools of the middle 1990s became extinct

RAD tools were focused on Desktop application development and web suddenly took over everything.

Yes, but the web was noticeably inferior as an application platform until html5, jQuery, Node and modern JS frameworks were being leveraged. But the web didn't require expensive licensing, and everyone by the late 90s had a web browser.

> web was noticeably inferior as an application platform

Nope. The web was both cross platform and insanely easy to use at the same time. It also cost an order of magnitude less because developers didn't have to implement an entire ui, printing and a bunch of code to make little things like the clipboard and resize window actually work. The web was vastly superior to the 1998 4gl scene and it was crystal clear in 98 that it was the future. So sure you could make a order entry crud app with your favorite 4gl and your order entry team could use it. With the web, I could make an order entry system and the whole world could use it...

I think one thing that killed the RAD market was it became viable to stick together a web application, especially since for a while no one cared if you included a barebones web server in your delivery

>Foreign keys? Let the business layer worry about rules like that!

Rails made this approach viable at the time.

> Rails made this approach viable at the time.

Rails didn't get big until 2006, eight years later than this time period =).

I still don't like using foreign keys. They just make things harder to work with for very little gain.

Wait for the crows.

Because of sharding, we can’t use them at work. I haven’t thought of foreign keys in years…

Care to elaborate? It felt like the best thing ever when switching to InnoDB.

Elaborate on what? They're an opinion that data integrity is dependent on foreign keys containing pointers at existing data.

In systems where actual row deletion doesn't actually happen its kind of a pointless kick to the nuts.

Now I have to create things in a specific order for no reason other than foreign keys say so. When you're using uuids for reference keys you're not beholden to what order you insert you can have these things span databases or have separate systems do the insert.

For a naive example, maybe I have an order A, and two orderliness A1, A2, why do I have to create A before I create A1 and A2. Why can't I loadbalance those three operations to different systems that insert at different timings.

Eventually they all line up, and my system is resilient enough to be ok with that.

With foreign keys you're just beholden to some feigned idea about data integrity but it's mostly bullshit.

The other common situation is when you need to backup tables and restore them elsewhere in whatever order you want, foreign keys just get in the way.

I see your point for decentralised systems, "eventual consistency" is an unavoidable evil in many cases there at least if you don't want a performance hole caused by distributed transaction requirements.

But otherwise, I disagree strongly.

> feigned idea about data integrity but it's mostly bullshit

I call BS on your call of BS.

> The other common situation is...

If that is common in your production environments, then I never want to work with your production environments.

> foreign keys just get in the way.

Disable them, do the jiggery-pokery, and then replace them. Again, but not in production systems.

If FKs are an inconvenience day-to-day then you have something seriously wrong somewhere. They are protection against bugs and other unpredictables causing corruption of data that other code later relied upon being correct.