I don't know the specifics of PHP and I personally don't care much, but it is just a matter of theory of computation anyways.
Could a language be translated into C to be compiled ? Sure. I don't know if it's the case for PHP, but it could.
Even in thay case, it doesn't mean that you're writing in C. It means that the compiler is not getting from the language all the way down to the opcodes. Instead, the compiler strategy is to translate to another language, C in this hypothetical case, and then call another compiler to take it from there to the final binary.
It is only a compiler strategy scheme, not a sort of set of "macros" trying to modify/prettify the C language into another one.
In fact. If later on someone decides to create another compiler, that doesn't use C as basis for translation, the source language will be exactly the same.
What's important to notice here is that the language doesn't matter. It's just an organizated way of talking to the compiler.
People tend to get less and less bound to languages when they realize that all of them are the same thing.
Structured programming, functional programming, object orientation... All of the same. They're all just different ways of talking to the compiler. Nothing fancy, nothing magical. Just the cold reality :)
I have not gone beyond the high level languages yet, but I remember a time when I thought Java's "write once, run anywhere" were unique among these languages. I've come to see it differently of late. Seeing a similar strategy as Java's being used in language like PHP (which I thought to be very different) just drives that point further. But then we have all this about JIT compiler and it's fast going beyond what I'm prepared to learn 😅 My surface level understanding of JIT compilers is like comparing them to how generators work - as in contrast to arrays. (arrays take up memory space equal to all its elements, while generators just have the potential for all the elements and return each as they're needed).
You should study data structure to get a better grasp of those kind of elements.
What languages provide in the standard lib (standard commands that they provide by default) are implementations of classical data structure algorithms.
Most of the modern languages end up implementing arrays using linked lists.
An array, in the traditional sense of the word, is a memory starting position and a length. So the index of the array is how much you increment the memory start position to get the next element.
So every array has to have a fixed length.
But languages can (and they do) encapsulate algorithms to make array expansion automatic, or they could even use linked lists, where each element of the array is comprised of at least 2 memory addresses: 1 for the data and 1 for the next element (or null)
So when you want to add something, you just come from the first element, then to the next, then to the next one... Until you reach the last one, than you can increment it by connecting it to the tail of that chain.
Variations of that algorithm use a little bit more memory in order to speed up add process...
To make the long story short, most of those data types they provide you will understand once you learn data structure.
Yes, I get that about arrays. I was rather thinking about arrays vs generators, as compared to compilation ahead of time vs just-in-time compilation. I don't know what languages you are used to but I believe that generators are not unique to PHP. I did a benchmark on a simple generator vs array the other day where a million-element long array with its printing took about 35.7MB of memory and the generator took 544 bytes. Quite the difference!!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I don't know the specifics of PHP and I personally don't care much, but it is just a matter of theory of computation anyways.
Could a language be translated into C to be compiled ? Sure. I don't know if it's the case for PHP, but it could.
Even in thay case, it doesn't mean that you're writing in C. It means that the compiler is not getting from the language all the way down to the opcodes. Instead, the compiler strategy is to translate to another language, C in this hypothetical case, and then call another compiler to take it from there to the final binary.
It is only a compiler strategy scheme, not a sort of set of "macros" trying to modify/prettify the C language into another one.
In fact. If later on someone decides to create another compiler, that doesn't use C as basis for translation, the source language will be exactly the same.
What's important to notice here is that the language doesn't matter. It's just an organizated way of talking to the compiler.
People tend to get less and less bound to languages when they realize that all of them are the same thing.
Structured programming, functional programming, object orientation... All of the same. They're all just different ways of talking to the compiler. Nothing fancy, nothing magical. Just the cold reality :)
Nothing is special, but incredibly fascinating!
I have not gone beyond the high level languages yet, but I remember a time when I thought Java's "write once, run anywhere" were unique among these languages. I've come to see it differently of late. Seeing a similar strategy as Java's being used in language like PHP (which I thought to be very different) just drives that point further. But then we have all this about JIT compiler and it's fast going beyond what I'm prepared to learn 😅 My surface level understanding of JIT compilers is like comparing them to how generators work - as in contrast to arrays. (arrays take up memory space equal to all its elements, while generators just have the potential for all the elements and return each as they're needed).
You should study data structure to get a better grasp of those kind of elements.
What languages provide in the standard lib (standard commands that they provide by default) are implementations of classical data structure algorithms.
Most of the modern languages end up implementing arrays using linked lists.
An array, in the traditional sense of the word, is a memory starting position and a length. So the index of the array is how much you increment the memory start position to get the next element.
So every array has to have a fixed length.
But languages can (and they do) encapsulate algorithms to make array expansion automatic, or they could even use linked lists, where each element of the array is comprised of at least 2 memory addresses: 1 for the data and 1 for the next element (or null)
So when you want to add something, you just come from the first element, then to the next, then to the next one... Until you reach the last one, than you can increment it by connecting it to the tail of that chain.
Variations of that algorithm use a little bit more memory in order to speed up add process...
To make the long story short, most of those data types they provide you will understand once you learn data structure.
Yes, I get that about arrays. I was rather thinking about arrays vs generators, as compared to compilation ahead of time vs just-in-time compilation. I don't know what languages you are used to but I believe that generators are not unique to PHP. I did a benchmark on a simple generator vs array the other day where a million-element long array with its printing took about 35.7MB of memory and the generator took 544 bytes. Quite the difference!!