5 ms·

> "Also, PHP is a fairly thin glue layer on top of a lot of C libraries" Your definition of thin, and glue are kinda... off.

by halayli 12y ago

pmelendez 12y ago
PHP is fairly thin (as a thumb rule the code size is roughly the same than Python) and it is a glue in the sense that you can consume the libraries in PHP instead of C. It is not the thinnest layer but I don't think his comment was off either.
- baldfat 12y ago
  I think the reason why is that PHP users always get picked on. (I up voted his comment)
  - oneweekwonder 12y ago
    Give me a sane way to remember when to add an underscore and when not to add an underscore after str: http://php.net/ref.strings http://php.net/ref.strings I wonder why they don't deprecate the str_* functions and create "normal" str{funcname} functions, for better consistency.
    - ygra 12y ago
      str without underscore is for functions that exist in C. They appear with the same name in PHP.
      - oneweekwonder 12y ago
        Am I missing strpos in C[1]? [1]: https://en.wikipedia.org/wiki/C_string_handling#Functions https://en.wikipedia.org/wiki/C_string_handling#Functions
    - toddan 12y ago
      And this is a reason to pick on people who use php?
      - crxgames 12y ago
        But it's so hip to do!
      - oneweekwonder 12y ago
        I did not pick on him or anybody else, I mentioned something that bothers me.
- 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.
- TazeTSchnitzel 12y ago
  PHP used to be thinner than it is now. PHP/FI 2.0 was a really thin layer on top of the C standard library, and you could trivially add new functions to it (though this is still true to an extent for Zend). PHP 3 and beyond have been more abstracted, thicker layers. They are platform-independent and have things like binary-safe strings and Unicode support.

> "Also, PHP is a fairly thin glue layer on top of a lot of C libraries" Your definition of thin, and glue are kinda... off.

by halayli 12y ago

> "Also, PHP is a fairly thin glue layer on top of a lot of C libraries" Your definition of thin, and glue are kinda... off.

pmelendez 12y ago

PHP is fairly thin (as a thumb rule the code size is roughly the same than Python) and it is a glue in the sense that you can consume the libraries in PHP instead of C. It is not the thinnest layer but I don't think his comment was off either.

baldfat 12y ago
I think the reason why is that PHP users always get picked on. (I up voted his comment)
- oneweekwonder 12y ago
  Give me a sane way to remember when to add an underscore and when not to add an underscore after str: http://php.net/ref.strings http://php.net/ref.strings I wonder why they don't deprecate the str_* functions and create "normal" str{funcname} functions, for better consistency.
  - ygra 12y ago
    str without underscore is for functions that exist in C. They appear with the same name in PHP.
    - oneweekwonder 12y ago
      Am I missing strpos in C[1]? [1]: https://en.wikipedia.org/wiki/C_string_handling#Functions https://en.wikipedia.org/wiki/C_string_handling#Functions
  - toddan 12y ago
    And this is a reason to pick on people who use php?
    - crxgames 12y ago
      But it's so hip to do!
    - oneweekwonder 12y ago
      I did not pick on him or anybody else, I mentioned something that bothers me.
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.
TazeTSchnitzel 12y ago
PHP used to be thinner than it is now. PHP/FI 2.0 was a really thin layer on top of the C standard library, and you could trivially add new functions to it (though this is still true to an extent for Zend). PHP 3 and beyond have been more abstracted, thicker layers. They are platform-independent and have things like binary-safe strings and Unicode support.