I think that proof of concepts are PHP’s greatest strength, actually.
These days it can be almost as strict as you want it to be, but it’s always been a “loose” enough language that you can implement things that work in very fragile ways and iterate at incredible speed.
When I am designing PoC microservices that will eventually end up running as Go or Rust, I often start with a prototype in PHP.
Sometimes when doing offensive security work you end up in the strangest environments with limited tools, odd quirks, broken shells, and god knows what else. But you know what is almost always available and just works? PHP.
I think people don't really realise that compilers are "difficult" projects in the same way as an appendicectomy is for a skilled surgeon, i.e. the surgery is
"routine" only because the surgeons spent decades honing their skills to do these routinely. The hard part was training someone to be able to do that.
Writing a compiler/interpreter is _extremely_ straightforward; a lexer -> parser -> ast -> semantic analysis -> {codegen -> linker | evaluator} pipeline is a very widely understood and tested way to write a compiler in any language, regardless of what language you are trying to compile. The hard part is _learning_ how it works, but after that implementing a compiler is a kind of mechanical activity. That's why LLMs are so great at writing parsers: they can just read the source of any compiler (and they probably read all of them) and apply the same stuff mechanically, with almost a 100% accuracy. We even have formal languages to define parsers and RTL and stuff, that's how "mechanical" the whole process can be.
I'm pretty sure that any skilled compiler dev with the ISO C standard and a few packs of Red Bulls can apecode a working C compiler in a few days, give or take. The hard part isn't doing that, the hard part is the decades of iterative improvements to make it generate extremely performant yet correct code as fast as possible.
That’s true for any software project - on average only 5% goes into developing of the first version, while 95% goes into continuous development, support, and maintenance.
21 comments
[ 3.0 ms ] story [ 36.5 ms ] threadThese days it can be almost as strict as you want it to be, but it’s always been a “loose” enough language that you can implement things that work in very fragile ways and iterate at incredible speed.
When I am designing PoC microservices that will eventually end up running as Go or Rust, I often start with a prototype in PHP.
https://github.com/mohsen1/fesh
Writing a compiler/interpreter is _extremely_ straightforward; a lexer -> parser -> ast -> semantic analysis -> {codegen -> linker | evaluator} pipeline is a very widely understood and tested way to write a compiler in any language, regardless of what language you are trying to compile. The hard part is _learning_ how it works, but after that implementing a compiler is a kind of mechanical activity. That's why LLMs are so great at writing parsers: they can just read the source of any compiler (and they probably read all of them) and apply the same stuff mechanically, with almost a 100% accuracy. We even have formal languages to define parsers and RTL and stuff, that's how "mechanical" the whole process can be.
I'm pretty sure that any skilled compiler dev with the ISO C standard and a few packs of Red Bulls can apecode a working C compiler in a few days, give or take. The hard part isn't doing that, the hard part is the decades of iterative improvements to make it generate extremely performant yet correct code as fast as possible.
Not sure if it was meant as a joke or not, but this cracked me up