3 ms·

Neither Python nor PHP are thin glues. They have their own GCs, and are byte code interpreted. How is that a "thin" glue on top of c? They are an environment on

by halayli 12y ago

Neither Python nor PHP are thin glues. They have their own GCs, and are byte code interpreted. How is that a "thin" glue on top of c? They are an environment on their own happened to be written in C.

pmelendez 12y ago
> They have their own GCs, and are byte code interpreted Between the thinnest alternatives I can think of (Scheme, Lua), they have GCs as well. I'm not sure why you are bringing memory manage here though. In that phrase the author is talking about the size of the language not the memory footprint. I believe that the author uses the term "glue" in the sense that a person who doesn't want to code in C can still use C libraries through a scripting language (in this case PHP). How else could you do it? Well you could do the same with Java using JNI. Also you could use Perl if you want but in comparison, PHP is "fairly" thin. The author is not claiming that PHP is lightweight, just that it is thin enough to be consired as a proxy between C libraries.
- pekk 12y ago
  "Thin" implies little work is being done over the work that C would do. I can't see how the size of the source repositories would matter here. Memory management is worth mentioning because actually it's a lot of work done automatically, and it is among the many important distinctions between code written in C and code which runs on an interpreter written in C. I doubt many people would have called Go a thin layer of glue over C even when it was implemented in C. There is, at least, the entire Go runtime to consider. By the time we've described almost every language in wide use as a thin glue over C (and so many languages do offer some kind of interface layer or FFI to C, permitting the use of C APIs outside of C)... there is no longer any real purpose calling anything a thin glue over C. So I have an alternative explanation: calling PHP a thin glue over C is just how PHP decided to market itself years ago, even though it's either not true or it's trivially true of almost everything else. The apparent idea was to encourage the thought that PHP is 'almost as fast as C' and to excuse very raw APIs (they have to be this raw, you see, in order to allow the high performance of staying close to C). I guess that made some kind of sense 15 years ago, and if you like PHP then at least there is still work on things like HHVM to reduce its disadvantages, but so much has happened in languages that now you can have either much cleaner APIs with comparable speed, or just plain much better speed than PHP, and there are also arguably options which have both cleaner APIs as well as higher speed. I'm not arguing that PHP is unusable, much less that PHP users are stupid, but it seems very strange to say words that seem to imply that PHP is faster than Perl and Java because it is closer to C, when PHP is not very close to C at all in any sense that everything else isn't also very close to C.
  - tedunangst 12y ago
    What would be an example of a thin glue? If your definition excludes all possibilities, it's no more useful than a definition that admits all possibilities.
  - pmelendez 12y ago
    I believe this discussion is getting long because it seems that everybody is using a different meaning for "thin". In this context (and it is a personal interpretation), a layer to interact with a C library is thin if there is not much code that separates a language to the other. In that regard it doesn't have anything to do with performance or memory footprint. If you take the way Java interacts with a C library you would see that there is a lot of code in between, that doesn't mean it is slower but it does mean it is thick in terms of the layer size. >but it seems very strange to say words that seem to imply that PHP is faster than Perl and Java because it is closer to C, I didn't imply that PHP is faster than Perl or Java. Just that PHP is thinner than them. However, this discussion is not going to be productive unless we all agree what we mean by a thin layer.

by halayli 12y ago

Neither Python nor PHP are thin glues. They have their own GCs, and are byte code interpreted. How is that a "thin" glue on top of c? They are an environment on their own happened to be written in C.

pmelendez 12y ago

> They have their own GCs, and are byte code interpreted Between the thinnest alternatives I can think of (Scheme, Lua), they have GCs as well. I'm not sure why you are bringing memory manage here though. In that phrase the author is talking about the size of the language not the memory footprint. I believe that the author uses the term "glue" in the sense that a person who doesn't want to code in C can still use C libraries through a scripting language (in this case PHP). How else could you do it? Well you could do the same with Java using JNI. Also you could use Perl if you want but in comparison, PHP is "fairly" thin. The author is not claiming that PHP is lightweight, just that it is thin enough to be consired as a proxy between C libraries.

pekk 12y ago
"Thin" implies little work is being done over the work that C would do. I can't see how the size of the source repositories would matter here. Memory management is worth mentioning because actually it's a lot of work done automatically, and it is among the many important distinctions between code written in C and code which runs on an interpreter written in C. I doubt many people would have called Go a thin layer of glue over C even when it was implemented in C. There is, at least, the entire Go runtime to consider. By the time we've described almost every language in wide use as a thin glue over C (and so many languages do offer some kind of interface layer or FFI to C, permitting the use of C APIs outside of C)... there is no longer any real purpose calling anything a thin glue over C. So I have an alternative explanation: calling PHP a thin glue over C is just how PHP decided to market itself years ago, even though it's either not true or it's trivially true of almost everything else. The apparent idea was to encourage the thought that PHP is 'almost as fast as C' and to excuse very raw APIs (they have to be this raw, you see, in order to allow the high performance of staying close to C). I guess that made some kind of sense 15 years ago, and if you like PHP then at least there is still work on things like HHVM to reduce its disadvantages, but so much has happened in languages that now you can have either much cleaner APIs with comparable speed, or just plain much better speed than PHP, and there are also arguably options which have both cleaner APIs as well as higher speed. I'm not arguing that PHP is unusable, much less that PHP users are stupid, but it seems very strange to say words that seem to imply that PHP is faster than Perl and Java because it is closer to C, when PHP is not very close to C at all in any sense that everything else isn't also very close to C.
- tedunangst 12y ago
  What would be an example of a thin glue? If your definition excludes all possibilities, it's no more useful than a definition that admits all possibilities.
- pmelendez 12y ago
  I believe this discussion is getting long because it seems that everybody is using a different meaning for "thin". In this context (and it is a personal interpretation), a layer to interact with a C library is thin if there is not much code that separates a language to the other. In that regard it doesn't have anything to do with performance or memory footprint. If you take the way Java interacts with a C library you would see that there is a lot of code in between, that doesn't mean it is slower but it does mean it is thick in terms of the layer size. >but it seems very strange to say words that seem to imply that PHP is faster than Perl and Java because it is closer to C, I didn't imply that PHP is faster than Perl or Java. Just that PHP is thinner than them. However, this discussion is not going to be productive unless we all agree what we mean by a thin layer.