As someone who has been programming for about 25 years now and has always been frustrated by the tendency of software devs, and in particular web devs, to not address the root issues but just scaffold on top of them and try to hide the ugly bits under the carpet, I feel a bit vindicated.

Everybody in the industry knows that we've been building on quicksand. Moore's law meant that we could just sacrifice performance and add a dozen layer on top of technology from the 90s (if not older) and keep the thing chugging along.

Look at the PHP situation:

- HTTP is an old and quirky protocol with a lot of surface open for attackers that are rarely useful nowadays and might be better left off to higher layers. But of course, we can't break compat, so everybody still implements all the naughty parts, just in case.

- PHP was a joke language from the start, we were making fun of it in the early 2000s, the fact that over 20 years later it still powers a huge chunk of the web is enough to demonstrate that we're not serious people. Cue the PHP fans telling me that "it's good now". Maybe, I don't really care, the effort that went into making it good should have gone into ditching PHP for a better language 20 years ago. The bandaid mentality is what got us in this situation.

- And of course to add insult to injury, PHP, this security-critical language, is still implemented in garbo C using things like setjmp/longjmp. Just to make sure to absolutely maximize the damage if a vuln is discovered, I suppose. Brilliant.

- Oh and all of this is still running overwhelmingly on top of x86 which is its own bag of legacy garbage. "No but you don't get it, modern CPUs are really more like RISC CPUs, the RISC ISA is translated internally" yeah exactly that's my point let's stop doing things like that.

We're a clown industry. We only made it this far because, usually, buggy code doesn't kill people and we can iterate and patch things quickly. We never had to do things correctly, we could flourish with abysmal levels of quality acceptance. This may not be true anymore.

Of course the reason things are done this way is generally to maintain backward compatibility and make transition easier. At least now that we have LLMs this excuse will hopefully vanish: porting even huge codebases to a new language/framework, something that was a tremendous undertaking mere months ago, is now vastly easier and faster. We can leave the 1990s behind us.

> We're a clown industry. We only made it this far because, usually, buggy code doesn't kill people and we can iterate and patch things quickly

I think you have things backwards. Devs aren't clowns who make it this far. But in industries where buggy code doesn't kill people, devs are expected to ship fast and iterate, because they can and more importantly, it serves the business.

Personally, I'm all about good software engineering principles, unfortunately I don't think you can last long in most companies if you're too opinionated about this and can't compromise (and it's getting even worse with AI, reading the code is no longer a requirement, go explain your teammate that there's an abstraction leak in their code...).

It's coordination problems and large scale distributed action, not some moral character of how serious the people are. Effort is not fungible. To make php good, you only have to act at one point, in a localized way, at the php foundation. To ditch php, you have to act in a coordinated way across any resource strapped companies and individuals. Just see how hard it was to ditch Python 2 or how ipv4 is still not ditched.

Trying to understand underlying reasons and incentive structures is much more productive and useful than simply venting about the worse moral character and seriousness of people in one industry vs the next. Curiously, the grass seems always greener - when you ask people in other industries, you'll often hear endless complaints about the state of things there too.

I have actually gotten a tremendous amount of value from PHP and WordPress: the via negativa! They showed me, in remarkable detail, how things should not be designed.

(I'm not kidding. If you take each element of their designs and invert it, you end up with a very solid design.)

On that note, I misspoke somewhat: I assert that PHP and JavaScript were not "badly designed", because that would imply that someone sat down, carefully considered how the different parts of the system interact, second order consequences etc. — and then somehow came to all the incorrect decisions. Rather, it's quite clear a serious design process has simply not occurred to begin with.

Once I recognized this phenomenon, I began to see it in all areas of life. Things are much worse than they could be, simply because nobody has designed them to be good. They just ended up the way they are now, by accident of history.

--

Polemic aside, I am fond of JS and PHP in many respects. I just think we should clean them up! "This mess has always been here, so it's too late to clean it now" would be laughed at in any other context.

We already broke compat with "use strict". Now we just need a "use sane" :)

> PHP was a joke language from the start.... Cue the PHP fans telling me that "it's good now".

First, I am not a PHP fan, but I will absolutely stick up for the "its good now".

Yes, absolutely no debate the old PHP 4.x/5.x was shocking. However to give PHP their due, they absolutely did make serious efforts in 7.x/8.x. They deserve due recognition for that.

Unfortunately lots of people – I'm guessing you're one of them – still have battle-scars from 4.x/5.x and they think (incorrectly) that 7.x/8.x is "more of the same".

Second "joke language", well, cast your mind back to what else was available at the time... ColdFusion, CGI, ASPX ... it was not exactly a beautiful world back then.

Sure, to borrow your terminology, the Java fans will be along soon to tell us all how awesome Java is for the web. But many of us still bear battle-scars of the horrors of Java stacktraces, messing around with incomprehensible XML config files, Java's penchant for eating RAM for breakfast, and generally trying to figure out why the hell Tomcat is not working (again !).

Non-technical managers don't want to wait for the 'nerds' to 'do it right' because that takes a long time and the nerds don't agree on how best to solve the problem because most capable nerds (who sort of know what they are doing) are working on lower-level problems and making the big bucks (they are not running WordPress for the local News Paper).

So that leaves non-technical managers telling non-technical nerds to just install WordPress. Then, AI comes along and wipes them out. And everyone is like... how did this happen?

It's pretty obvious.

>We're a clown industry. We only made it this far because, usually, buggy code doesn't kill people

Another industry is does even better: the medical/health industry. It's both a clown industry AND kills people AND they have made it way beyond what software can only dream.

Another thing that has bothered me for a long time: we have far too many data isolation mechanisms, each with their own idiosyncrasies and trying to cover up for each other's gaps. Very very roughly, from source code up:

- Variable naming conventions (_field in Python).

- Lexical scopes.

- Visibility annotations (public, private, protected).

- Coroutines, threads.

- Packages/modules.

- Sandboxes.

- Processes.

- OS capabilities (pledge/unveil, SELinux, etc).

- Local user accounts.

- File permissions.

- Containers/chroot.

- User mode vs kernel (Ring 0 vs ring 3).

- Virtual machines.

- Secureboot, attestation, encryption of data-in-use, etc.

On the other hand we have few mechanisms to share data: the filesystem, clipboard, sockets, maybe dbus. Shared memory?

If a script wants to know what file is currently open on my editor or what email attachments I recently uploaded, the editor or email client has to explicitly implement this feature via one of those limited mechanisms. Almost nobody does this, so we're stuck with black box applications that are hostile to customization.

> PHP was a joke language from the start

I am no fan of PHP but it wasn't really a joke language. Its goal I think was to add some dynamic snippets to your homepage for which I guess it served its purpose pretty good. PHP even originally stood for Personal Home Page iirc. The problem seems to be that the rest of the language was built on top of that. I haven't used PHP in over a decade, so I don't know if it's still the case, but you used to start a PHP file with a PHP opening tag, which is such a weird "feature", but I guess kinda makes sense in a world where everything outside of PHP tags used to be HTML.I remember seeing PHP files that were impossible to work with: thousands of lines with HTML mixed in with PHP classes etc.

> to not address the root issues but just scaffold on top of them and try to hide the ugly bits under the carpet, I feel a bit vindicated.

There's only one area I sorta give a pass, and that's mainframes. It takes an insane amount of physical servers to replace a mainframe. Why IBM didn't invest more into making mainframes a drastically better platform for devs is beyond me. I don't know that any other server platform has ever achieved the level of uptime a mainframe has.

Still, it is no excuse to leave them with ultra legacy code that remains unmaintained for decades.

> Oh and all of this is still running overwhelmingly on top of x86 which is its own bag of legacy garbage. "No but you don't get it, modern CPUs are really more like RISC CPUs, the RISC ISA is translated internally" yeah exactly that's my point let's stop doing things like that.

The interesting thing is that memory bandwidth has become a big issue. CISC instructions take up less space than the equivalent RISC instructions, so you can effectively get more instructions per cache line. Effectively the CISC to RISC conversion acts as a type of decompression. Because if that, stopping the CISC messiness without moving to a compressed instruction stream would actually hurt performance.

> We're a clown industry.

I'll generally agree, and I include myself in this industry, but we've simply have been bound by compatibility. I don't think anyone chose intentionally to keep the crap around; it was simply never worth it to pay the "break compatibility" cost, until now.

> we're not serious people

Absolutely. The industry could have moved towards safer languages, better coding methodology and formal verification years ago (see for example MISRA C as at least a partial movement in this direction). It didn't, because it was cheaper not to.

To me this is just yelling at clouds.

Things have moved on from PHP, but at the time, the alternatives had many more tradeoffs in a wide range of cases. Without PHP the internet would have unfolded much differently, much more slowly.

The "bandaid" mentality you decry exists of course, and is outright bad in some cases, but is just good business in many others.

Rewriting everything makes no sense. And, of course, in the vast majority of cases is never going to happen, so advocating for that is effectively advocating doing nothing at all for 90%+ of sites. A much more efficient and effective approach to using AI here would be to find and fix issues in the PHP runtime, and to assist in automating the deployment of the runtime. Time spent on this fixes thousands and millions of sites at a time, in a consistent, improvable way, rather than one at a time, in a piecemeal way.

> We're a clown industry

I think if we want to bring more engineering discipline to software development, we need sober analysis, not outraged rants.

Oh I assure you, all industries are clown-driven, clown-built, and clown-maintained. Nobody has time to do things according to a retrospective analysis of "best" which will just be re-evaluated next generation. We build with what we have and fix when we must.

(SRE here)

Exactly. There was even a whole domain of expertise (SRE) that exploded because of the lack of engineering rigor. That's not to say if everyone did all the right things all the time there would be NO need for SREs, but there would be fewer of us - something that I've tried to communicate to everyone I've worked for in the past ~14 years of being one.

But we had to deliver. We had to increase shareholder value.

Just goes to show how quality never is and never was a key to success. Same with JS. That trash only became successful (widely used and popular) because it was conveniently available in the browser and hit a user need.

Maybe… it’s about money? As long as companies get away relatively small fines for massive private data leaks, who cares? Equifax anyone?

Still, I pray you’re right.

> As someone who has been programming for about 25 years now and has always been frustrated by the tendency of software devs, and in particular web devs, to not address the root issues but just scaffold on top of them and try to hide the ugly bits under the carpet, I feel a bit vindicated.

Not sure why you would. It seems like the people who made these compromises were roughly right and the problem only escalated when it also came with a solution.

The reason PHP and other, "joke languages" are still in use is because business needs power businesses, not engineering wants. Plenty of businesses are still run on pen, paper, and custom spreadsheets because those things just work or work well enough. Could they do a better job or scale up more with a SaaS offering or two? Possibly, but why?

Your desire is not to build things on quicksand but your solution is to just throw LLMs at everything and rewrite it all? That's not the solution and causing even more rapid churn by ditching backwards compatibility is just going to exacerbate the problem.

This goes double when you add in the same non-technical-sourced pressures that caused developers to take shortcuts are still there, and now even worse with their unrealistic expectations for LLMs.

I hope that the current enclosure of hardware + the help of AI means that we might finally, finally have an era of optimization in which software is made to run much better on existing and older hardware. How nice it would be to have an OS and basic software that opened instantly, responded as soon as I clicked, etc.

> PHP was a joke language from the start, we were making fun of it in the early 2000s, the fact that over 20 years later it still powers a huge chunk of the web is enough to demonstrate that we're not serious people.

Don't forget the other half of the web development stack: Javascript. The absolute worst scripting language ever desi--well no, it wasn't designed, it just kind of happened accidentally. At least PHP solved a problem of the day, Javascript was nonsense from the start, and somehow managed to become critical infrastructure.

Not sure if I disagree with all your points, but this one caught my attention:

> HTTP is an old and quirky protocol with a lot of surface open for attackers that are rarely useful nowadays

HTTP 1.x is that, perhaps. But I was in the trenches when HTTP/2 came out, brand new and running on binary. It was so new that there were very few implementations around, and my team had to code one. The people who worked on the spec had a lot of learning to apply from HTTP 1.1. That resulted in many nice bits in HTTP/2, but HTTP/2 also had serious issues at a spec level. Which is my way of saying that "modern" doesn't necessarily mean "bug free".

It seems "coding AIs" can enable the final form of coding (end game): binary specs with direct assembly implementations. No more compilers.

Just for my curiosity could you name a non-clown industry?

My guess is aviation or .. defense?

We don’t have billions to throw away on making sure our about-dialog is memory safe.

Yup. Another reminder of how far software engineering lags behind other engineering disciplines in rigor and accountability. The chickens are coming home to roost.

This is also a result of consumers putting up with every kind of shit they've been dealt. The application layer has been the biggest resource hog.

I get your drift but... This sounds a bit like advocating "why not ditch all progamming languages and build some super language that makes no exploits possible". While we are at it, ditch the Von Neumann architecture. Or saying "why not ditch all natural languages in favor of Esperanto".

> the effort that went into making it good should have gone into ditching PHP

What effort? PHP foundation has one employee!

> The bandaid mentality is what got us in this situation.

> We're a clown industry.

We are clown industry becauee nobody would sponsor solid research, infrastructure and fixing all those bugs! PHP is junk literslly written over nights by some volunteers!

> HTTP, naughty bits

It's especially fun when not implementing the naughty bits is its own source of vulns. Your code is simpler and less prone to RCE, but your proxy mishandling or whatever allows for credential smuggling attacks, identity spoofing, request smuggling, cache poisoning, and all the normal issues at the application layer.

The amount of begging I've had to do as a Ruby on Rails dev to be given time to refactor debt was unreal. This was pre-AI, around 2018.

I basically just worked extra unpaid hours with a colleague to do it since it was frustrating. Not even from a security standpoint as it is now, but just plain developer happiness.

But while we were cleaning the Swamps of Dagobah the other team was extending them.

Our deliverance came when the other team got woo-ed by React and started coding less in Ruby.

For my mental sanity I treat the React project as a black box.

Just heard they had to update the Redis connection configuration in 6 places, after we had switched to Sentinel based connections.

I seriously can't with my people sometimes.

You forgot NPM. Whereby we download code from unknown authors on GitHub and run in with full access to our filesystem on our machines. No vulnerability, it's been designed like this, we even have designed scripts to autoupdate vulnerabilites, that's the proof that vulns are not common.

>to not address the root issues but just scaffold on top of them and try to hide the ugly bits under the carpet

It's totally the devs fault and not the environments devs have to work in. Deadlines forced down on you until you have to make compromises, 24/7 having to compete with people who actually don't care because you have to meet months end payments somehow. Whole businesses blinded by a tech gold rush.

>We're a clown industry.

I do agree here, but that includes every non dev person.

I think we need to start over with safer languages and runtimes.

That’s what I started to do 10 months ago.

You want a safer language AND transpilers from PHP, JS, Python etc. into it? So you can find issues in your original code using source maps, or just speed up your PHP by 10x and your Python by 100x? Here you go:

https://ulanguage.org

The thing that pisses me off about people who complain about PHP is that all these smarty pants people have pointed out the flaws in PHP, but never really understood why it was successful, and because of that they never created a language that could succeed it. The things that made PHP successful were:

1. It just werked. You could write incredibly shitty code and it, like HTML, would work as long as there wasn't a fatal error. And sure you could just say "git gud", but that's not going to happen. People will just use the best language that works for them, and in this case, it was PHP.

2. It required very few resources to run low to medium traffic websites. Because of the Apache mod_php module, PHP sites wouldn't use any resources if they weren't being served, unlike every other language at the time. So it meant places could host thousands of websites on the same server no proble.

The guy who created PHP, Rasmus Leerdorf, never wanted and never expected that PHP would become as popular as it has. He has mentioned that he thought that at any moment, someone was going to come around and create a language that would succeed PHP. But it never happened. People are just better at pointing and complaining instead of solving the issues that people want solved.

We are not a clown industry - we are an evolved industry - both parts of that matter. We evolved in an environment where these kind of attacks were not possible or were freak, state sponsored events. Kind of like moving from a sheltered lagoon to the Pacific Ocean. And we are an industry - where profit matters. Open source was lead by people like you who cared and did not have profit to constrain them. Which is why it’s better engineered (and frankly if open source like Linux or FreeBSD had not existed in our lagoon, the profit would have failed earlier and commercial Linux would have had to been built and built to same standard (god knows how)

But we are out in the pacific now, and boats that sink make no profit, so we will evolve again, and again.

But it’s hard to blame Moana standing on a pacific island for not inventing a nuclear powered battleship.

(Trying not to be too blame-y on either side)

>frustrated by the tendency of software devs, and in particular web devs Are you sure that's not the typical cost optimisation of management/c-levels rather than a developer problem?

What you wrote reads a bit like ye olde typical "nyeeeh javascript! you're only a dev if you write everything in assembly! kids these days!"

We all know software is swiss cheese. Now it wil be swiss cheese with duct tape on it. So what.

Or have the devs been Vindicated as AI is the newest scaffold

This sounds like "I told you so".

What the heck have you been doing instead of pointing out the obvious?

Are you sure you are senior? Because in my 22 years of experience in 3 countries and host of employers (banking, telco, insurance, military, municipality, energy distribution, retail etc) it was always management setting the tone and only fools ignore the hand feeding you and go against it due to some 'higher principles'.

No we don't need to have documentation and keep updating it what you can't read code? No we don't need to rewrite system that was patched ad absurdum so codebase became fragile and its hard to navigate layers of abstractions. We need to deliver this project yesterday at all costs since somebody up there slept on requirements for 6 months and didn't do their basic job, and we will never pick up half-assed pieces we were forced to deliver. No we don't need to update those 12 years old libraries, too much work and testing. I could go on and on.

It seems like you consider engineering to be delivery of perfect things, or utter failure. Thats not how things are anywhere, sw dev is more unstructured but you also don't have 5 million ways to build a good wall using every possible substance in the universe, do you.

[dead]