> 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.

> 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.

What industry do you think is different?

I've had a decent amount of construction work done on my house, and if I had a pound for every shortcut that the guys doing the work took, it would pay for the work they did. And these are the _good_ ones. The bad ones don't even bother following the legal requirements. Somewhat recently [0] it was found that less than half of healthcare workers followed recommendations on _hand washing_.

[0] https://www.cambridge.org/core/journals/infection-control-an...

> 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 !).

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" :)

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

Another industry 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.

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.

I use to joke about PHP in the early 2000s, but now that I see the "better languages", I am starting to like PHP.

If you want a web page that works with a database (aka. CRUD), presents it in HTML form, and with a bit of business logic, like 90% of websites, then PHP does it simply. None of these astronautic patterns like you see in Spring, the dependency hell that comes with node, or whatever the cool kids are using right now. There is a reason PHP became so successful despite the hate it gets.

PHP is not great for security, it was terrible when it started, but now it is decent. And sure, a vulnerability was found, it is now fixed, every time a vulnerability is found and fixed, PHP becomes better. New technology may have an advantage due to better design, safer languages, etc... but you shouldn't dismiss the qualities that 20 years of bugfixes get you.

As for x86, yep, it is legacy, but it is not completely stupid either. The "RISC core" is not right, it is not like x86 become ARM or RISC V code internally. It is translated into long microcode-style instructions that wouldn't make sense as an ISA, where a compact representation is important for memory/cache reasons. RISC code is also translated just like x86 code, and the advantage of CISC vs RISC has gone back and forth. Now it seems we are going back towards RISC again, but before that, it was CISC, and before that, RISC again. The quirk about x86 that complicates things seems to be the variable length instructions. But the real problem is not really about which ISA is the best (it is a very small part of modern CPUs), it is more about licensing and backwards compatibility.

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.

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.

- Cryptographic measures (secureboot, attestation, memory encryption, etc).

On the other hand we have few mechanisms to share data: the filesystem, clipboard, sockets, maybe dbus. Shared memory if you're feeling brave.

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.

> 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.

It's simply not realistic to expect the entire world rewrite its entire technology stack from scratch, starting at the transistor level on up every time there's a new industry innovation in security or performance.

LLMs might make this somewhat easier, but you're still going to have to deal with backwards compatibility and legacy systems. Completely eliminating the use of architectural cornerstones like x86 or HTTP or even PHP across the entire industry isn't going to happen anytime soon, let alone overnight, especially if the only argument for doing so is "we could design this better if we implemented it from scratch".

> 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.

Quality software is out there, but you have to pay for it.

(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.

> 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.

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.

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.

Was it software devs? I've always had the impression it was management that didn't want to give us time to address technical debt, but just focus on shipping more features.

I've certainly taken time to address tech debt whenever I could. Which was not as often as I'd like.

> 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.

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?

> the tendency of software devs, and in particular web devs

Software devs absolutely love to create a mess, and are never challenged by business, product, management, or you name it, to increase speed to market, cut down cost estimates and, to say it crudely, deliver half-assed work.

Systemic issues have systemic consequences.

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".

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".

> 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.

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.

sorry, but you are really naive. php was peak engineering compared to the contrived layers of llm generated executable pseudocode we are about to build upon for the foreseeable future. php is opcode running in a C/C++ driven virtual machine. what llms are spitting out is statistically inspired plagiarisations void of sense that linguistically abstract non-linguistical concepts chaining all that crap then build towers of it and nobody will be able to even reason about what's going on without adding more llm to the mix. think apollo guidance computer but 1TB of code.

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.

Haha, so how do I become a palace clown? Just kidding. I like and trust AI, but I don't think AI can solve the debt, because AI code creates a different type of debt than code written by humans.

> 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!

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

> We never had to do things correctly, we could flourish with abysmal levels of quality acceptance. This may not be true anymore.

Ironically, the opposite is the case with LLMs. Now those on your teams that wanted to stop the clownery will be overruled by the vast amount of bullshit code from their less skilled peers. Of course, those that care can use LLMs to faster clean up, but there's no way they are able to keep up.

Managers always favored outcome over correctness, and not giving two shits about the internals was, and will always be, incentivized.

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.

We can now leave the 1990’s behind us by generating code non-deterministically.

At least put some formal verification on top of that GenAI pile.

"We're a clown industry."

How can even call this an "industry"

On the RISC stuff specifically: It sounds like you're saying CISC is just RISC with a microcode translation layer. It's not wrong, but then RISC is also RISC with a microcode translation layer.

The CISC vs RISC debate hasn't been interesting in a quarter century at least. The only real difference is that the instruction decoding (which CISC and RISC both have) is likely going to need more transistors on x86 than other contemporaries.

But I'm not sure what you mean by "stop doing things like that". The ISA is "the API". Sometimes the best CPU implementation (for whatever definition of "best") will need to change the ISA-to-microcode translation.

It's not reasonable to assume that a decades old ISA will have a 1:1 instruction to microcode mapping. Hell, it's not even 1:N. Macro-op fusion makes the mapping N:M. So you could say that RISC also has variable length instructions, in a way.

And RISC-V has two sizes of instructions, with RVC. So it's not even "super transistor efficient because all instructions are 32bit".

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.

Yeah, I just don't see how every chrome or even firefox tab has to consume 500 mbs each, it's actually insane, even for basic websites like HN

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.

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.

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

>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!"

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.

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

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