5 ms·

That's an interesting comparison, because under the hood Cython and LuaJIT FFI could hardly be more different. Cython is an optimizing Python (+ extensions) ->

That's an interesting comparison, because under the hood Cython and LuaJIT FFI could hardly be more different. Cython is an optimizing Python (+ extensions) -> C compiler. LuaJIT FFI is a library for Lua. It doesn't change the language at all (there are none of Cython's optional annotations), there is no build-time tool or need to run a C compiler. But I can see how they could serve some of the same use cases.

_dps 12y ago
"LuaJIT FFI is a library for Lua. It doesn't change the language at all ... " This is literally true, of course, but in my ~5 yrs using it now I can say that writing LuaJIT+FFI-data-type code is, for me, both aesthetically and mechanically different from writing plain Lua code. The post captures it quite well: This is basically the inverse of the old promise that languages like Python came with: that you would write your whole application in Python, optimise the “hot spots” with C, and voila! C speed, Python convenience, and money in the bank. This was always much nicer in theory than practice. In practice, your data structures have a huge influence on both the efficiency of your code, and how annoying it is to write. I often write my LuaJIT programs from the ground up designed around C data types and C-style memory allocation discipline. Bu I can always ditch that in areas where I know I don't care (e.g., configuration loading etc where 10 lines of C become a 1-liner in Lua).
dang 12y ago
In both cases a tool is being adapted for something it wasn't intended for: to write C-style code—specifically, code that works with memory the way C does—in a high-level scripting language. This way of combining high and low levels within the same program seems qualitatively unlike, say, C++, traditional FFIs, and other answers to this problem. It's fascinating to see it emerge from more than one existing technology.
- maxerickson 12y ago
  "Python with C data types" was somewhat of a design goal for Pyrex, the language that Cython followed/built on: http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/version/Doc/About.html http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/ver...
  - dang 12y ago
    That's fascinating because it is very much about the same problem.
    - maxerickson 12y ago
      I guess I'm not sure which tool you meant was adapted; Cython (and Pyrex) certainly adapt Python to work more directly with memory, but I would say the style of code in the article is an intended use case of them. (I also might have undersold the connection between the two, Cython is arguably just a friendly fork (I guess mostly they wanted to move faster))
      - dang 12y ago
        I just meant that the OP is adapting Python (via Cython) similarly to how FFI-driven LuaJIT adapts Lua. The resulting programming style is different enough from classic Python or Lua that it approaches being a different language—something like an embedded C DSL.

_dps 12y ago

"LuaJIT FFI is a library for Lua. It doesn't change the language at all ... " This is literally true, of course, but in my ~5 yrs using it now I can say that writing LuaJIT+FFI-data-type code is, for me, both aesthetically and mechanically different from writing plain Lua code. The post captures it quite well: This is basically the inverse of the old promise that languages like Python came with: that you would write your whole application in Python, optimise the “hot spots” with C, and voila! C speed, Python convenience, and money in the bank. This was always much nicer in theory than practice. In practice, your data structures have a huge influence on both the efficiency of your code, and how annoying it is to write. I often write my LuaJIT programs from the ground up designed around C data types and C-style memory allocation discipline. Bu I can always ditch that in areas where I know I don't care (e.g., configuration loading etc where 10 lines of C become a 1-liner in Lua).

dang 12y ago

In both cases a tool is being adapted for something it wasn't intended for: to write C-style code—specifically, code that works with memory the way C does—in a high-level scripting language. This way of combining high and low levels within the same program seems qualitatively unlike, say, C++, traditional FFIs, and other answers to this problem. It's fascinating to see it emerge from more than one existing technology.

maxerickson 12y ago
"Python with C data types" was somewhat of a design goal for Pyrex, the language that Cython followed/built on: http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/version/Doc/About.html http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/ver...
- dang 12y ago
  That's fascinating because it is very much about the same problem.
  - maxerickson 12y ago
    I guess I'm not sure which tool you meant was adapted; Cython (and Pyrex) certainly adapt Python to work more directly with memory, but I would say the style of code in the article is an intended use case of them. (I also might have undersold the connection between the two, Cython is arguably just a friendly fork (I guess mostly they wanted to move faster))
    - dang 12y ago
      I just meant that the OP is adapting Python (via Cython) similarly to how FFI-driven LuaJIT adapts Lua. The resulting programming style is different enough from classic Python or Lua that it approaches being a different language—something like an embedded C DSL.