4 ms·

For all practical purposes, a programming language is defined by it's general real world implementation, and not it's specification. Maybe not so much for compu

For all practical purposes, a programming language is defined by it's general real world implementation, and not it's specification. Maybe not so much for computer scientists, but for programmers, Python is interpreted with some JIT alternatives and C++ is compiled.

okaleniuk 4y ago
Numba is a Python compiler for heterogeneous programming. It builds kernels with the same back-end NVCC does. With the equivalent AST, the kernel code it also equivalent. We adopted it last year, and we don't rewrite code in C++ for GPGPU anymore. We save tons of effort on rewriting and even more on support. How is this computer science?
zelphirkalt 4y ago
This is false. Making a new implementation is a practical purpose. Any new implementation will have to work with the spec, instead of idiosyncracies of other implementations. Ergo there are practical purposes which go by how the language is defined in its specification. Some languages have more of a proper spec than others, of course. If we look at for example Scheme dialects, then they often change their implementation for better conformance with the various rnrs standards. New Scheme dialects often early on try to conform very much to the standard to avoid issues later on.
- IshKebab 4y ago
  > Making a new implementation is a practical purpose. Not yet it isn't. At least not for Python. I mean there are plenty of alternative implementations of Python but they aren't practical because they don't work with CPython modules (as far as I know anyway) so approximately nobody uses them. The de facto spec is "what CPython does".
  - cirospaciari 4y ago
    PyPy work well with CPython modules but the performance is not that great, with CFFI performance is really good in PyPY, HPy project will change this https://hpyproject.org/ https://hpyproject.org/
    - deleted 4y ago
      [deleted]
    - throwaway894345 4y ago
      Last I checked, Pypy wasn’t compatible with many important packages in the Python ecosystem. As of a couple years ago, there was no trustworthy, supported package for talking to a Postgres database with Pypy because psycopg2 wasn’t supported.
      - svth 4y ago
        I've been using PyPy and psycopg2cffi in production for the last 5-6 years or so without any issues. https://pypi.org/project/psycopg2cffi/ https://pypi.org/project/psycopg2cffi/
        throwaway894345 4y ago
        Interesting. I wasn't able to get that working when I tried several years ago. I forget the specific issue.
      - qorrect 4y ago
        When is the last time you checked ? I have run it with pandas+numpy and postgres+timescale without issue for the last year.
        throwaway894345 4y ago
        Several years ago now.
    - cirospaciari 4y ago
      postgresql can work with psycopg2 but is not the same performance as psycopg2cffi , i will integrate some databases to PyPy, and also HPy project will bring any Cython library to PyPy with basically the same performance or better.
  - okaleniuk 4y ago
    I heard that very argument about GCC. C++ without __attribute__ is not practical for embedded development therefore C++ for PLCs is what GCC does. And yet, the general consensus now is that C++ is ISO/IEC 14882, and what GCC does is just an implementation. With Python, you don't even have to go "alternative" to use LLVM compiler infrastructure. You can use CPython + Numba and compile your kernels for both CPU and GPGPU on the go. Which is very practical. Which is ironic, to compile a CUDA kernel in C++, you would have to use an alternative NVidia implementation of the language.
okaleniuk 4y ago
I literally posted the links to the AOT Python compiler and to the C++ interpreter.
- ddalex 4y ago
  A theoretical difference without practical impact; nobody uses these - sure you can implement a C++ interpreter in hardware if one so wishes, but if the industry doesn't use it, what's the good of it ?
- messe 4y ago
  The commenter above you said: > general real world implementation By this they mean the real-world-implementation that is in general use, which in this case is interpreted. Yes, Python can be compiled and C++ can be interpreted. 99% of the time, they're not though. When somebody says X language is interpreted, they mean that the most common and widely implementation is an interpreter. That's a useful bit of information to know about a language. "Correcting" them and saying that all languages can be interpreted OR compiled, doesn't really add anything of value to the discussion, other than to label yourself as a pedant.
  - okaleniuk 4y ago
    Counterexample. Numba is a Python compiler for heterogeneous computing. We adopted it last year and stopped rewriting code in C++ to run it on GPGPU. On one hand, the conception from the 90s based on the most common Python implementation, on the other - a compiler that saves us tons of money. Which one adds value again?
- mindcrime 4y ago
  I literally posted the links to the AOT Python compiler and to the C++ interpreter. That would be important in high-school debate club. In the real world, most people don't care about obscure edge cases and pedantry. In the industry vernacular, Python is an "interpreted language" and C++ is a "compiled language". Arguing against that in anything other than a highly (highly!) specialized context is just lighting candles in the wind.

okaleniuk 4y ago

Numba is a Python compiler for heterogeneous programming. It builds kernels with the same back-end NVCC does. With the equivalent AST, the kernel code it also equivalent. We adopted it last year, and we don't rewrite code in C++ for GPGPU anymore. We save tons of effort on rewriting and even more on support. How is this computer science?

zelphirkalt 4y ago

This is false. Making a new implementation is a practical purpose. Any new implementation will have to work with the spec, instead of idiosyncracies of other implementations. Ergo there are practical purposes which go by how the language is defined in its specification. Some languages have more of a proper spec than others, of course. If we look at for example Scheme dialects, then they often change their implementation for better conformance with the various rnrs standards. New Scheme dialects often early on try to conform very much to the standard to avoid issues later on.

IshKebab 4y ago
> Making a new implementation is a practical purpose. Not yet it isn't. At least not for Python. I mean there are plenty of alternative implementations of Python but they aren't practical because they don't work with CPython modules (as far as I know anyway) so approximately nobody uses them. The de facto spec is "what CPython does".
- cirospaciari 4y ago
  PyPy work well with CPython modules but the performance is not that great, with CFFI performance is really good in PyPY, HPy project will change this https://hpyproject.org/ https://hpyproject.org/
  - deleted 4y ago
    [deleted]
  - throwaway894345 4y ago
    Last I checked, Pypy wasn’t compatible with many important packages in the Python ecosystem. As of a couple years ago, there was no trustworthy, supported package for talking to a Postgres database with Pypy because psycopg2 wasn’t supported.
    - svth 4y ago
      I've been using PyPy and psycopg2cffi in production for the last 5-6 years or so without any issues. https://pypi.org/project/psycopg2cffi/ https://pypi.org/project/psycopg2cffi/
      - throwaway894345 4y ago
        Interesting. I wasn't able to get that working when I tried several years ago. I forget the specific issue.
    - qorrect 4y ago
      When is the last time you checked ? I have run it with pandas+numpy and postgres+timescale without issue for the last year.
      - throwaway894345 4y ago
        Several years ago now.
  - cirospaciari 4y ago
    postgresql can work with psycopg2 but is not the same performance as psycopg2cffi , i will integrate some databases to PyPy, and also HPy project will bring any Cython library to PyPy with basically the same performance or better.
- okaleniuk 4y ago
  I heard that very argument about GCC. C++ without __attribute__ is not practical for embedded development therefore C++ for PLCs is what GCC does. And yet, the general consensus now is that C++ is ISO/IEC 14882, and what GCC does is just an implementation. With Python, you don't even have to go "alternative" to use LLVM compiler infrastructure. You can use CPython + Numba and compile your kernels for both CPU and GPGPU on the go. Which is very practical. Which is ironic, to compile a CUDA kernel in C++, you would have to use an alternative NVidia implementation of the language.

okaleniuk 4y ago

I literally posted the links to the AOT Python compiler and to the C++ interpreter.

ddalex 4y ago
A theoretical difference without practical impact; nobody uses these - sure you can implement a C++ interpreter in hardware if one so wishes, but if the industry doesn't use it, what's the good of it ?
messe 4y ago
The commenter above you said: > general real world implementation By this they mean the real-world-implementation that is in general use, which in this case is interpreted. Yes, Python can be compiled and C++ can be interpreted. 99% of the time, they're not though. When somebody says X language is interpreted, they mean that the most common and widely implementation is an interpreter. That's a useful bit of information to know about a language. "Correcting" them and saying that all languages can be interpreted OR compiled, doesn't really add anything of value to the discussion, other than to label yourself as a pedant.
- okaleniuk 4y ago
  Counterexample. Numba is a Python compiler for heterogeneous computing. We adopted it last year and stopped rewriting code in C++ to run it on GPGPU. On one hand, the conception from the 90s based on the most common Python implementation, on the other - a compiler that saves us tons of money. Which one adds value again?
mindcrime 4y ago
I literally posted the links to the AOT Python compiler and to the C++ interpreter. That would be important in high-school debate club. In the real world, most people don't care about obscure edge cases and pedantry. In the industry vernacular, Python is an "interpreted language" and C++ is a "compiled language". Arguing against that in anything other than a highly (highly!) specialized context is just lighting candles in the wind.