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.
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...).
But explaining that openly, as is your duty, means surfacing something which could be read as 'bad work' by a non-technical manager unable to grasp the complexity. So in low-trust teams it very quickly becomes a game of brinkmanship, or a prisoner's dilemma for technical diligence
My manager can’t understand the RFC, and knows that clean up projects aren’t palatable to his senior eng leadership so he keeps asking me to simplify or derive some business justification. I’ve proposed superficial ones like improving security posture etc but he wants a hard number that can be measured (yet another senior leadership mandate).
I’m kind of exasperated and honestly think it’s his job to figure this out.
I now work in a highly regulated field (payments/banking) and it's a bit better, but from prior experience if there's no regulator to beat people with, they will simply not give a shit, the only thing they want is to shove out whatever feature as fast as humanly possible.
As an example GDPR was a godsend because I could finally convince people to get rid of the 11 trillion stupid analytics and tracking bullshit we had "Because GDPR", whereas no number of arguments, no matter how well researched and presented, would ever convince anyone before
Business people should understand, at a high technical level, how their products work and what they’re actually asking to implement.
I’ve worked with many great business analysts and product people and consistently the best ones are the ones with the “engineer brain”. They might not know how to read even a single line of code, but they understand software products from their pieces. Those people consistently propose high-quality and feasible solutions. Other business people do not.
As developers, we are expected to constantly think on our feet and adapt. We learn new products and methods on practically a weekly basis. But for whatever reason, the business folk are not even expected to understand the product they help build. There’s such a large disconnect there between dev and business.
If higher-ups have no technical insight, round up and give them two numbers: $$ if a bad thing happens, and $$$$$ if the worst thing happens.
The director of my department kept asking, "But do we HAVE to do this now?", so my final answer was this:
"Do we _have_ to? No, but it's like a bridge. Bridges have an expected lifespan when they're built, and they're supposed to be torn down and rebuilt after that. It's not a HARD limit, though. The bridge doesn't immediately collapse the day after its lifespan, but there are fault accumulating. Metal fatigue, erosion of support material, and other things. Commuters can't tell the bridge is past its lifespan, and they'll continue crossing it every day without issue. And then one day the issues will accumulate to the point that the bridge fails and people DIE. That's the situation we're in with this stack. It will continue to function just fine until the day it doesn't, and on that day I won't be able to tell you how quickly we'll be able to recover the application stack, if at all."
That FINALLY got through to him.
If someone says that something is a risk and we should address it, I don't expect a director to ask for a specific date the risk to become a disaster. Instead, he should just add it to some todo list and slot some time to analyze it and and budget resources. AKA, doing some "management" work. You shouldn't have to explain his job. You didn't need to learn semiconductors physical properties to know that storage can fail and you need to do backup.
The logical extrapolation of AI capabilities stress-testing human software is all bugs being discoverable. Hence, you have to aim for actually bug-free software.
The only way to do that is to make your code provable. That again is only realistically doable using AI.
In the process, people will have to turn the current mere pretense of software engineering into reality, making the engineering part explicit.
That in turn only works when humans actually understand what they're doing and can communicate it to outsiders.
But shipping faster was pushed at almost every company until, if it's not revenue generating, stop putting resources into it. Not all are like this but it's not all or nothing, it's always a sliding scale how much you can put into making the software correct.
There are things you buy out there that don't need Swiss quality because most people will simply not need the quality or won't have the money to pay for it.
I think the biggest problem isn't that a random webpage is sloppy, but when a critical system that could kill people is built the same way as the random webpage.
Near the point where things become minorly safety critical, people will blur the line. The point where safety kicks in moves a little further out, and we start blurring the lines again.
There’s a reason the FAA is anal-retentive about things with only very minor safety implications, like the in-flight entertainment system or turning on airplane mode. It helps prevent complacency where it actually really does matter.
You either do it the right way 100% of the time, or I’m not taking bets that you’ll do it right on a particular occasion.
> eventually I realized that if I didn't get things out of the door, my company would start losing money and I'd lose my job.
This is like 90% because most tech is different enough that civil torts don’t exist for them yet, so they don’t have to care.
Eg if Google deletes all your photos they kind of just shrug and you’re out of luck. If I deposited photos at a bank who burned them without notice or approval, they’re on the hook for that.
The law will eventually catch up and acknowledge that bits can have value. Then everyone will have to care again.
We track EVERY requirement to ensure it is met. Maybe it's a safety issue; maybe it's landscaping approvals (I work in Rail). Regardless, it's bigger $ if not caught up front, and if you start grading requirements on perceived risk, you start the slippery slope to not caring. Example: mark all landscaping requirements as "Not Critical". Then scheduled clearing of the right-of-way is missed. Then pedestrians are at risk with blocked line-of-sight, and trees might drop across the rail.
What that PE certification will check? That guy knows how to write unit tests? Well, that's not much. Who will write certification? Where's that genius, why he's hiding from the rest of us?
Maybe building is figured out. I don't know. I still see bridges failing and buildings crushed, so apparently it's not perfect. But I do know that programming is not figured out. Absolutely not. We can apply tremendous effort, pay billions and produce some simple firmware which can be uploaded to a martian rover. But that doesn't scale to the rest of industry.
Then when company forces a product to skip safety checks, test units. And the PE proves the did their but the company pushed forward, the company gets wide open to fines and lawsuits.
Make a company responsible and hit their bottom line, other will think twice before they say "just ship it, or I'll hire someone cheaper to do it". And no they don't say that, that's how it's done.
When your paycheck or livelihood is on the line, you tend to slowly sacrifice the principles.
I think your being short sighted here. And a aggressive for no reason.
The cost of "losing customer data" is too abstract for a company trying to survive financially. Corners will inevitably be cut.
Unless the costs to be suffered by the company for exposing private or sensitive information are made very clear through legislation.
2026 is saying "here is the consequence."
Explain those super human hacking AIs like the ones that broke containment and hacked outside sites are coming for your infrastructure too.
All the business people have heard about the Huggingface incident by now (or are living under a rock).
Look at the solo projects from professional devs with nobody overseeing them. Look at what so many of your colleagues submit despite the frustration of your thoughtful team lead and manager. Look at what your so many of your team leads asks for even when they've been granted full discretion. Some select few are great, but most are disturbing if you have any sense of quality or preparedness yourself.
Even for decades before AI, there was lazy naive misguided slop everywhere. During the social coding era of the last 15 years this even amplified itself, streamers and influencers and conference presenters -- professional developers themselves -- would share horrid practices to wide applause. Moving fast and breaking things was what developers were excited about. Rigor was dead. Correctness was a problem for later. Code was presumed best written by a rando on github who'd accumulated a lot of stars rather than by a known responsible hand. Security was a copy and paste job from Stack Overflow, not something to be comprehended and considered.
If only it were a top down problem from outsiders!
But the truth is that the call has been coming from inside the house all along, and the outsiders giving direction have had no problem finding celebrated industry "experts" and "thought leaders" affirming and encouraging all the clowning they could imagine.
Developers could always move fast and do things right but most just didn't have any interest in learning how, and many of those who might have just gave up on bothering.
In fact, I have myself spent years on solo projects with the goal of making perfect software. You know, nothing like getting a few users to quickly destroy that idea from your naïve brain. You can’t write perfect code because that is nearly impossible for most of us, no matter how hard and how long you try. Think of it like this: can you beat the greats in your favorite sport or hobby? Probably not, you may be good at a small team level, but at a large city level you are almost certainly mediocre. This goes for your coding skills too. How many great developers out there creating great software we all know and use and love? I know a couple of names, that’s it. Most of us are writing shit enterprise applications everyone who is forced to use hates and that has more bugs than PHP in the early days. And when we try our own thing it’s even more horrible. Show me your repos and let me se if you’re the genius you think you are. Oh of course, you don’t have time to spend on hobby projects since you have a life… great, enjoy that, but don’t pretend you’re able to paint the Mona Lisa just because you spend all day with a brush in your hand striking on a canvas that no one can really see and if they did, it would most likely be a repulsive, incomplete, bug hidden piece of shit.
Just take a look at some of the opensource academic, infrastructure or "passion-projects", where there is no management pressures to "move fast & break-things" and ship-ship-ship. They tend to be very stable, very predictable - and very high quality.
I've seen software that academics write. It's no better than average. It's often cut-and-paste code, or these days AI slop. Software is a means to an end in academia, rarely a product in itself.
Some of them are, most are not.
Actually, most FOSS stuff is anything but stable or predictable. Instead it is constant treadmill, broken compatibility, and recently, thousand of commits from claude et al.
That might be true on the margin, but highly doubt it was ever true once you escape a very shitty local optimum.
https://ijcionline.com/paper/13/13224ijci12.pdf
Wow, it’s almost like it’s really hard to get everything perfectly right and this is endemic to software, particularly when the language accepts incorrect code.
The only two things we know mitigate this are proofs (eg rust borrow checker, lean, etc) and DST which is basically the equivalent of accelerated time testing which is done in other industries too. Most people don’t even bother with property testing
simias referred to the industry and you took it personally.
Why is it whenever someone mentions the shortcomings of software industry, there is always a comment saying "no no no, developers were just following orders!"
Sounds like they’re talking about devs
I don't disagree with the point that a lot of software that isn't pressured to be shipped quickly still ends up following bad practices, but I don't think we can ignore that the quality issues in software aren't also found all over in many industries because of profit motives?
But also every developer has a responsibility. At least not to promote any technology which is part of the problem.
Yeah, but money.
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.
This isn't unique to coding, but coding has been built on it for decades, with the "safety valve" of "who has the time to check all that?". So defcon speakers and intelligence agencies burn time investigating for weak links that might take months to find, and the rest of the world churns on.
Now you have companies throwing thousands or millions in compute at problems just checking EVERY possible problem and yeeeeup, looks like there's a lot of "good enough, ship it" which is now a major problem for all those companies using that tech.
It's still going to be interesting to see how this develops because, yes, there's a lot of code being written by people who haven't even read it (although the amount of enterprise production level code I've seen that's bad stack overflow copy paste makes me less worried about this), and there's maybe better tools and standards to catch these things (why not spin up a test suite if it's an afternoon of AI poking rather hiring a dev and getting them up to speed?).
I’ll keep checking
I tend to write integration tests for the paths users take through the application (website), and fill in the holes with unit tests. I'll also write unit tests for methods that change often or are critical, such as business logic.
https://mbrock.github.io/filnix/docs/php.html
It’s also compatible with most PHP native extensions.
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 !).
Pffft. VRML is the whole game, baby! Once everyone runs out and gets an SGI oxygen, Nobody is going to use freaking web browsers ever again. I mean, HTML, what a joke.
Classic ASP was the more direct competitor to PHP, while ASP.net came along later, as part of a next generation of web server languages/frameworks/platforms.
The other option I was actually offered was in machine learning and categorisation, but I avoid it as it was obviously a dead end lol.
well, there's no Java2Shell at least.
Ahem, cough....
Log4Shell (CVE-2021-44228)
Unless you count the XML dependency management with Maven, which isn't too bad.
I suspect the only thing that's changed is that Oracle now charge you for the pleasure. ;)
More seriously though, its been a long time since I've touched Java, but I suspect the only thing that's changed is that its all hidden in magical kubernetes containers these days.
Congratulations Java Fan on missing BOTH the smily-face at the end of the first phrase AND the "More seriously though" at the start of the second.
I'm glad someone still loves Java though. ;)
P.S. The kubernetes reference was – since that one appears to have gone over the top of your head too – that in todays world Kubernetes is extraordinarily popular and therefore it is likely most people now hide the complexities of Java deployment into a container that is magically generated and deployed through CI/CD. Hence I was inferring that life is probably "easier" today with Java because you just deploy the magical container.
Although that was more connected to the performance improvements through Zend Engine than language sanity or robustness, at the time.
You’re missing the point. Those are all dead. The implication is that PHP should have had the same fate.
That's a C language error, not a PHP language error. I don't see that CVE as particularly different from when they showed python's dictionaries could be attacked using dictionary hash-collision (something that also affected PHP). It's worse in being remotely executable, rather than merely a denial of service, but it's ultimately a facet of the C implementation rather than something wrong with the language itself. CVEs, even remote ones, will happen. Even java had its logging execution attack.
I've made fun of plenty of things in PHP over time, but the language hit the mark it was aiming for initially. It was easy. A 12 year old could sit down and write an ugly little forum and it would work. Because it was easy for amateurs, a lot of amateurs wrote in it, and there's a ton of clumsy code out there. Because it was easy to setup and run with minimal setup, popular packages were very popular. Wordpress vulnerabilities matter because it was very easy for programming chop shops to hack out tons of websites for all the millions of little businesses out there that didn't often follow up on patching etc once that was done. PHP was bad largely for the same reason BASIC was bad. It was easy.
PHP being easy gives it a huge blast radius for anything that goes wrong with its implementation or popular frameworks and libraries.
(I say this as someone who enjoys C programming)
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...
There are plenty of software projects that are managed to an incredibly high standard professionally - OpenBSD, PostgreSQL, Curl all come to my mind pretty much immediately. Linux is probably the closest thing to "skyscraper" development and has been going for 35 years at this point.
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.
In the end, PHP wasn't great, but around 2000 it was a great intro to building things on the web.
Verbosity of a language/framework is meaningless now. Pick a language or platform that makes it as hard as possible to write insecure code, no matter the tedium, and let a coding agent bang away on the keyboard for you.
Complex architectures are even worse, again due to limited context. LLMs work well at the function level but have trouble seeing the "big picture". I would argue that working with agents is all about managing context and things like skills, subagents and the practice of writing plans are just a way to optimize context use. If you could stuff your entire code base in there with full attention, it would be much easier, but the costs of doing this would be prohibitive.
PHP is hard to beat for development velocity. Edit a file, refresh a page in your browser, see the results.
Now that people are back to writing their applications in languages that aren't as slow as Ruby they've, in many cases, taken the server back out of their application and have returned to the CGI model again; what is often marketed as "serverless".
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.
The big fun factor is the place in the Venn diagram where they both intersect. I used to work for a medical device manufacturer who's biggest and most popular product routinely had stack traces at inopportune times.
(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" :)
I don't think it holds with
> If you take each element of their designs and invert it, you end up with a very solid design.
The rule of thumb is "the inverse of stupidity is not intelligence". So, if we have an example where you can get a good design by inverting the bad one, we can't then state that the bad one was a result of a chance. The probability is very low.
For example, in one case, the toilets were flooded, and they spent nearly an hour arguing about whose fault/responsibility it was. I snuck off quietly and solved the problem. (This offended them, presumably because then they couldn't bitch about it anymore!)
Anyway, I started keeping a list of complaints — all the ways that job violated my standards. At first, naively, thinking "surely if I show this to mgmt they will fix things!", and later, "ok, red flags list for next job."
At some point I realized I had actually created a spec for the perfect job, but with each term inverted:
Abusive assholes -> respectful colleagues
Total lack of process and communication -> a place that's actually functional and well thought out
Everyone hates their job -> people actually want to be there and enjoy what they're doing
Mindless drudgery -> creative and technical challenges
And so on. Amusingly, inverting the shitty kitchen job produced an almost exact description of VALVE corporation.
Anyway, I'm sure there's a term for this. Maybe "negative space"?
- 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.
The data is already in memory and the source program knows its "shape"; there should be an easy mechanism to provide access to that by default, like /proc or gdb but for arbitrary data structures and with better UI.
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.
This is not completely a bad thing. Using skyscraper techniques for dog houses is not sustainable.
The key is to identify when you are working on a skyscraper and when you're working on a dog house and act accordingly. To my mind, the boundary between the two is whether or not you are handling sensitive personally identifiable or financial data.
>So that leaves non-technical managers telling non-technical nerds to just install WordPress.
Good summary of how the world operates generally everywhere. It's a clown world.
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.
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.
In theory CISC instructions take less space than the equivalent RISC instructions, but x86 has lots of legacy features which makes it far less efficient than a CISC could be.
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.
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.
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".
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.
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.
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.
This was the tradeoff (or should I say trade-up) for going from
#!/usr/bin/perl -w
use strict;
my $username = <>;
chomp($username);
# blah blah blah blah blah
print "<html>\n<head>\n[...]<body>\n";
print "<p>Hello, " . $username . "!</p>";
print "</body>\n</html>";
<html>
<head>[...]
<body>
<p>Hello, <?php echo $username; ?>!</p>
</body>
</html>
Anyway, for (hopefully) your enjoyment, here's my best fizzbuzz golf (but not the best):
for$n(1..100){$\=$/;$n3=$n%3;$n5=$n%5;print!$n3&&!$n5?fizzbuzz:!$n5?buzz:!$n3?fizz:$n}
2. Really cobbled, and in all seriousness that's why I say I don't know Perl (I only did any of this stuff with very heavy reference to documentation and no real sense of orientation at all)
bonus: https://i.vgy.me/Q5qIIP.png
> 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".
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.
Who's we?
The issue is simple: YOU work for clowns who prioritize financial success above all else, including quality of output. You usually don't have the ability to say "No" to a bad decision made by a senior person. Deadlines, managers dumping more work, feature creep, etc. Then, when you can't deliver they taunt you for their incompetence. So you eat shit all day long churning out crap. That or management hires the bottom of the barrel because its cheap and maybe one or two seniors who eat turd sandwiches all day, give up and ship shit. Enjoy workplace hell. Fire your incompetent boss.
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 risk is of course, an earthquake where it could destroy all houses built before year X.
But we do the same in all industries, path of least resistance.
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.
While yes, PHP begun as a collection of macros and was never intended to be a programming language, JS was made by someone with intention. To quote from wiki,
> [Eich] originally joined intending to put Scheme "in the browser", but his Netscape managers insisted that the language's syntax resemble that of Java. As a result, Eich devised a language that had much of the functionality of Scheme, the object-orientation of Self, and the syntax of Java.
I've seen quotes before from Eich himself I believe that he was combining these influences at the time - Scheme's closures, Self's prototypes. It didn't "just happen".
Still, I pray you’re right.
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.
There quality should be there, but it should only ever be “good enough”
I bring this up because it's the first thing that popped into my head thinking about PHP's legacy. And, admittedly maybe it's not the best analogy, but when people shit on the caissons that bridged the internet because it seems crazy in hindsight to continue use those techniques, shit dreamed up by wacky people to do the impossible, or maybe said we should tear it down and build it a different way, the reality is that sometimes you just leave the bridge in place and improve where you can. It's still standing, you know?
I might be stretching here with all this, but despite you making some very defensible points, I just don't buy into the whole narrative. Just because retrospection has blessed us with the ability to intellectually point out that we built things on quicksand doesn't mean that there were real alternatives to build on at the time. The ease and speed that things like PHP provide(d) allowed enough things to be created to make the web as we know it coalesce into existence in the first place. Pedantic or more expensive or arguably safer choices easily could have slowed progress to a crawl, OR you just build the bridge and see if it's still standing 143 years later.
And in some cases, it is.
[0] https://www.pbs.org/kenburns/brooklyn-bridge
I've certainly taken time to address tech debt whenever I could. Which was not as often as I'd like.
The Morris worm was already a sign, but alas, as long as there is no punishment, no one cares, like buying at those 1 € shops.
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'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.
You don't see the same problems in say, structural engineering as you do in software engineering. I suggest this is due to needing to go through the formal training required of a structural engineer, and membership bodies like chartered institutions, with standards and codes of ethics. We might want to reflect on that
No amount of bureaucracy and process theater gets around this fact. There is a vast and very expensive gap in software between "don't do stupid things" and "this is actually correct". The tooling to close this gap is severely deficient and not for lack of trying. In physical engineering we've had automated design checking for decades because it is a relatively trivial problem in those domains.
It would be great if compilers could generate proofs but after decades of research they can't even generate SIMD code in most contexts.
I rarely call myself an 'engineer', preferring developer or programmer.
In Europe, a lot of supermarkets were hit by a remote exploit which allowed attackers to switch off cooling of food. A blood bank in France was attacked the same way.
So how would building software for important or even safety-relvant systems not be considered "engineering"?
Especially, as faulty software might not only cause a product or device to fail in a dangerous manner, faulty software in this day and age often makes it possibly to remotely attack the faulty product.
I think that has more to do with than some unverifiable sentiment like "software people are simply inherently less serious than other engineers".
So "downloading" part is just looking similiar.
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.
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!
And yet everyone knows this, and millions of people still continue to use it and develop new software with it, to avoid learning from our mistakes. The software industry is just not interested in fixing these problems; I've heard people upset that AI is pointing out flaws, instead of being upset that flaws exist. Deeply unserious.
Also, path-dependency is a real issue everywhere. You would know that if you would actually experience true industries. All in all, software world is far more malleable than anything.
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.
My guess is aviation or .. defense?
We don’t have billions to throw away on making sure our about-dialog is memory safe.
The real clowns union paradoxically is the least clownish industry one can find.
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.
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".
Then there's the "reverse micro-op" that is instructions intended to cause traps for software to handle. E.g. Alpha's PALcode that handled (among other things) unaligned memory accesses.
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!"
At least put some formal verification on top of that GenAI pile.
How can even call these people an "industry"
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:
What the heck have you been doing instead of pointing out the obvious?
Your analysis is severely flawed and naive.
Software devs often patch and sidestep the root issues for the same reason why every single engineering field resorts to patching ans sidestepping root issues.
Why do you think there is such a thing as aviation duct tape? This is a field where people's lives are on the line.
There is a very puerile belief around opinionated junior devs which an inconvenience in the code justifies redesigning whole systems, even if they are still quite capable of performing their functions. Things need to be clean and ideally elegant, and any minor deviation is cause to tear everything down and start over.
In the meantime, experienced and competent engineers instead get the system back in working order and downgrade the criticality of existing issues until it's convenient to address them.
Go ask a project manager if all bugs should block a release, or if it is ok to release something with a known bug. Listen to them. Perhaps then you'll understand why patching works.
I'll believe it when I see it.
Otherwise, I completely agree.
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.
Been saying to boos and rotten veggies "it's just electrical state in a machine; yall are deluding and debasing yourself for money." And "if you want to improve security stop using leaky abstractions to configure your machines".
Even better is that AI is replacing all knowledge work it just reinforces how absolutely bonkers the US "services economy" is and giving social stature to credentialed randos whose skills are whittled down to cooking frozen meals, grubhub, and Excel Sheet expert; unserious country peddling before the eyes of the poorest manual workers all these years that their degree in accounting earned them the right to wander through someone's home town across the world via resource intensive travel
Or better yet just being born rich earns them that!
This is an unserious country and social culture top to bottom to continue to assume modern people of nations rebuilt since Murica bombed them to the stone age don't see how Americans are drinking their own piss since the end of WW2; refusal to acknowledge externalities like generational churn (among all the others) makes it clear America is an unserious country.
HR and accounting and even a law degree do not make the individual worker bee irreplaceable themselves; whole lot of arrogant low skilled "knowledge workers", biological fuzzy VHS of often debunked pseudoscience studies now 30 years outdated... can pound sand.
Set aside the circumlocutions inherent to old thinkers like Marx and Adam Smith and capitalism is a social/communal discovery of services and prices; seems pretty fucking social and communal. But that's not "the Sacred Jedi Texts!"[1]
Top to bottom American society is a clown car stuffed full
[1] will take to my grave Luke screaming about Jedi Sacred texts was a metaphor for dogmatic people in general
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)
That’s changed - we are in stormier weather and need better boats, but it would have been unlikely to have built battleships to sail the lagoon just in case…