I got my real professional start using PHP, and have built even financial systems in the language (since ported to .NET 6 for my ease of maintenance, and better number handling). I'm still very interested in the language itself, in case I ever have the need to freelance or provide a solution to a client that can't afford what I can build in .NET (although to be honest, at this point I'm roughly able to code at the same speed in .NET as in PHP, but with the added type-safety, although I know PHP has really stepped up in providing this).

Regular PHP strings are actually pretty great, since you can treat them like byte arrays. Fun fact: PHPs streaming API has an “in-memory” option and it’s… just a string under the hood.

Just don’t forget to use multibyte functions when you’re handling things like user input.

Weird book IMO, because it has a lot of content that's just about general software development, rather than anything to do with PHP specifically, or the theoretical PHP6 APIs in particular.

https://www.joelonsoftware.com/2000/04/06/things-you-should-...

An oldie but a goodie

You should rewrite code only when the cost of adding a new feature (one that is actually necessary) to the old codebase becomes comparable to designing your entire system from scratch to allow for that feature to be added easily. That is to say that the cost of the rewrite should become comparable to the cost of continuing development. I have been a part of a couple of rewrites like that, one of them quite complex, and yes they were warranted and yes they worked.

But having said that you should absolutely be conservative with rewriting code. It’s a bad habit to always jump to a rewrite.

I don’t think you necessarily need to be conservative about rewriting things. We do it all the time in fact. We build something to get it out there and see the usage, and then we build it better and then we do it again. Which often involves a lot of “rewriting” but thanks to principles like SOLID’s single responsibility makes this rather easy to both do and maintain (we write a lot of semi-functional code and try to avoid using OOP unless necessary, so we don’t really use all the parts of SOLID religiously).

I do agree that it’s never a good idea to get into things with the mind-set of “we can do this better if we start from scratch” because you can’t.

Why not identify that same logical feature and move it into a library. How does a Microservice add value here?

Identifying, extracting and adding tests to logical features has been the sane way to rewrite software for ages. Michael feathers even wrote a book about it [1]. This ship of theseus approach works because it's incremental and allows for a complete rewrite without ever having non-functional software in between.

Adding a REST/networking/orchestration boundary to make it a Microservice just for the sake of extracting it adds a lot of complexity for no gain.

Microservice can be the right architecture, but not if all you want is to extract a library.

[1] https://understandlegacycode.com/blog/key-points-of-working-...

You shouldn't stop development on your important products.

Letting a couple of your talented programmers loose on a greenfield reimplementation is a perfectly sane strategic move.

Stopping development on important products because you are 100% certain that the reimplementation will be successful by $DEADLINE is a foolish gamble.

Between the 3 P's, Python's strategic decisions in 2000s were clearly the most successful.

And it wasn't a total rewrite.

So in order for there to be a net gain, the gang working on the alternative have to be able to find such big wins as to being neigh impossible.

This is a very very hard problem in our domain. 99% of the time, we have to simply resist the urge to _just rewrite the sucker_. No! Don't do it! (And this is incredibly hard because we all want to.)

Say you have product A with features P, Q, R, and S; writing product B has to reproduce P, Q, R, and S, plus X and Y that is currently produced by the A team. On top of that, it has to fix (conceptual) bugs within P, Q, R, and S. All this is to be done by the new, crack, team that aims to make it so that: cost-of-development(B) < cost-of-development(A).

But the point is that the difference in magnitude of cost-of-development(B) and cost-of-development(A) has to be rather large considering the amount of work needed to have a return on that investment at all.

> They decided to rewrite the code from scratch.

Absolutely not what's being proposed for Postgres.

In practical terms, if every line needs to be audited and updated, it is a re-write

Experience with other systems has taught me that in a system that's been in active use and development for decades, entanglement will be deep, subtle, and pervasive. If this isn't true of postgres then it's an absolute freak anomaly of a codebase. It is in other ways, so it's possible.

But the article mentions there being thousands of global variables. And Tom Lane himself says he considers it untenable for exactly this reason. That's a very good reason to think that it will require that many changes imo.

The 'that many changes' in question is a complete rewrite. Many changes across many files, yes, but nothing even approaching a rewrite.

> I don't have any particular knowledge of postgres

Judging by their bio, the person you're replying to does.

A large refactor at best. It will touch lots of parts of the code base, but the vast majority of the source code would remain intact. Otherwise they could just Rewrite it in Rust™ while they’re at it

> if every line needs to be audited and updated, it is a re-write

I’m not sure why you believe every line needs to be updated. Most code is thread agnostic.

One of the main programmers suggested making it so that the next guidance routine wouldn't run until the previous one was done. This would make the code less sensitive to race conditions and allow more useful functionality for the pilots (who were the actual users and did seem to want it). However everyone assumed the two-second constant was implicitly embedded everywhere.

It wasn't -- only in a few places -- and with that fixed the code got more general and the proof of concept ran better than ever in about every simulator available. The amount of control it gave pilots was years ahead of the curve. But it never got a chance to fly on a real mission because what was there was "good enough" and nobody bothered to try.

In our combined comments there's a lesson about growing experiments and figuring out how to achieve failure quickly.