4 ms·

You raise a good point, but the OP's point still stands. All we'd need is comments in header files with the extra type information encoded, and automated FFI wo

You raise a good point, but the OP's point still stands. All we'd need is comments in header files with the extra type information encoded, and automated FFI would be possible. Not to say that would be easy... building a type system on top of a language that lacks it is anything but easy, but it's possible. TypeScript is an excellent example.

roca 5y ago
The OP's point is very clearly "we could just parse C header files and do it all automatically", not "we could parse C header files and a bunch of extra handwritten metadata and then do the rest automatically". The latter point is certainly more defensible but it's not the point they made, and it's much weaker ... I mean of course if you add extra metadata you can generate whatever FFI glue you need. The devil is then in the details.
- philipswood 5y ago
  I took his point in general to be a rant about the unwillingness to give priority and effort to things that are schleppy, but doable. An unwillingness to address the devil in the details. The main idea being that an unwillingness to solve these problems once, generally and completely is dooming "us" to solve it partly, inefficiently and repeatedly. I would take the detail he gives for the specific cases as incomplete. Specifically this one. I would NOT say that the article as a whole is "clearly "we could just parse C header files and do it all automatically"" All of these should be doable. Each of these obviously has significant schleppy or technical difficulties/constraints. For none of these does he address the actual reasons they haven't been done or suggest plans for overcoming them. I kinda agree with him at a high-level in this case FFI _should_ be solvable. I think for this case he's just saying "there should be _some_ way to automatically generate FFI glue code (and we should be reusing it)"
  - roca 5y ago
    I respect you for generously steelmanning the OP's argument here but it is very clear the OP's intent is "just parse C header files and do it all automatically": > not only could you technically parse .h files and turn them into JNI Well, no, technically you can't do that at all.
    - philipswood 5y ago
      OK. Fair interpretation. The OP didn't have much leg to really stand on for this point and glosses over any of the actual difficult work that would need to be done to make this utopia from the 70/80/90s materialize. It's not a great post, and its ideas are not that clearly worked out. He could seriously work on his tone. It could be parsed minimally as a just a grumpy rant with a bit of "get off the lawn" and a few wrong ideas. Mostly a waste of time. I'm steelmanning it because personally I'd prefer to get as much as possible from what I've read. Even if it wasn't necessarily put it in the first place (maximizing my utility from it, for my purposes). I'm not debating the OP. If you're acting from a position of keeping him honest. Kudos. So I don't really need to engage you on the point then. I'm agreeing that you'd probably be able to take down the OP in an argument. Or at least would force him to up his game considerable to be able to actually make his points clearly. BTW, I really like your use of "steelmanning" here. Actually looking at his other points after this exchange: (2) I think modern VMs have amazing engineering - is he asking for hacks? Or what? (3) Cloud offerings could be more coherent. But there are real market and organisational constraints. (4) Drag and drop UI designers would be nice, and I miss them, but even the good ones used to produce terrible code when used innocently. (5) I think modern compilers are pretty awesome. Not sure what he wants done. (6) Yeah. We could build better more compact systems. His unhappiness at the state of the world. Hmm. Moaning about it like that doesn't really do much to solve it...
jolux 5y ago
I think having to manually annotate C headers with extra type information starts to reduce the benefits of automatically generating FFI interfaces. Rust already has bindgen which goes pretty far.
nixpulvis 5y ago
Did you just imply that we put the comments of C headers into our types?! Comments are lower than whitespace as far as the compiler should be sure. As I'm sure you are aware https://github.com/rust-lang/rust-bindgen https://github.com/rust-lang/rust-bindgen does basically what you want. I'm actually quite curious where exactly rust-bindgen falls short in the eyes of the author. I'm not as familiar with the other FFI libraries the OP linked.
- DonHopkins 5y ago
  When is SWIG finally going to support Generalized Whitespace Overloading in C++ 2000? It's been 23 years, 2 months, and 19 days since the technical details were published in AT&T Labs Technical Report no. 42! https://www.stroustrup.com/whitespace98.pdf https://www.stroustrup.com/whitespace98.pdf
masklinn 5y ago
> All we'd need is comments in header files with the extra type information encoded, and automated FFI would be possible. That’s SWIG. It’s something like 15 years old, possibly more. > building a type system on top of a language that lacks it is anything but easy, but it's possible. TypeScript is an excellent example. That has nothing to do with the issue at hand. You can compile haskell to c, that does not help FFI-ing to unannotated C functions.
- DonHopkins 5y ago
  https://en.wikipedia.org/wiki/SWIG https://en.wikipedia.org/wiki/SWIG >Initial release February 1996; 25 years ago http://www.swig.org/history.html http://www.swig.org/history.html >July, 1995. Dave develops SWIG while working in the Theoretical Physics Division at Los Alamos National Laboratory. Originally, it was conceived as an extension building tool for a customized scripting language that had been created for the Connection Machine 5. David Beazley, the author of SWIG, is a brilliant programmer, mad scientist, and excellent presenter. https://en.wikipedia.org/wiki/David_M._Beazley https://en.wikipedia.org/wiki/David_M._Beazley https://www.dabeaz.com/ https://www.dabeaz.com/ Check out his many talks about programming, especially his epic PyCon 2014 talk on his work as an expert on a patent infringement case. https://www.youtube.com/user/dabeazllc/videos https://www.youtube.com/user/dabeazllc/videos https://www.youtube.com/watch?v=RZ4Sn-Y7AP8 https://www.youtube.com/watch?v=RZ4Sn-Y7AP8 >David Beazley: Discovering Python - PyCon 2014 >So, what happens when you lock a Python programmer in a secret vault containing 1.5 TBytes of C++ source code and no internet connection? Find out as I describe how I used Python as a secret weapon of "discovery" in an epic legal battle. >Slides can be found at: https://speakerdeck.com/pycon2014 https://speakerdeck.com/pycon2014 and https://github.com/PyCon/2014-slides https://github.com/PyCon/2014-slides

roca 5y ago

The OP's point is very clearly "we could just parse C header files and do it all automatically", not "we could parse C header files and a bunch of extra handwritten metadata and then do the rest automatically". The latter point is certainly more defensible but it's not the point they made, and it's much weaker ... I mean of course if you add extra metadata you can generate whatever FFI glue you need. The devil is then in the details.

philipswood 5y ago
I took his point in general to be a rant about the unwillingness to give priority and effort to things that are schleppy, but doable. An unwillingness to address the devil in the details. The main idea being that an unwillingness to solve these problems once, generally and completely is dooming "us" to solve it partly, inefficiently and repeatedly. I would take the detail he gives for the specific cases as incomplete. Specifically this one. I would NOT say that the article as a whole is "clearly "we could just parse C header files and do it all automatically"" All of these should be doable. Each of these obviously has significant schleppy or technical difficulties/constraints. For none of these does he address the actual reasons they haven't been done or suggest plans for overcoming them. I kinda agree with him at a high-level in this case FFI _should_ be solvable. I think for this case he's just saying "there should be _some_ way to automatically generate FFI glue code (and we should be reusing it)"
- roca 5y ago
  I respect you for generously steelmanning the OP's argument here but it is very clear the OP's intent is "just parse C header files and do it all automatically": > not only could you technically parse .h files and turn them into JNI Well, no, technically you can't do that at all.
  - philipswood 5y ago
    OK. Fair interpretation. The OP didn't have much leg to really stand on for this point and glosses over any of the actual difficult work that would need to be done to make this utopia from the 70/80/90s materialize. It's not a great post, and its ideas are not that clearly worked out. He could seriously work on his tone. It could be parsed minimally as a just a grumpy rant with a bit of "get off the lawn" and a few wrong ideas. Mostly a waste of time. I'm steelmanning it because personally I'd prefer to get as much as possible from what I've read. Even if it wasn't necessarily put it in the first place (maximizing my utility from it, for my purposes). I'm not debating the OP. If you're acting from a position of keeping him honest. Kudos. So I don't really need to engage you on the point then. I'm agreeing that you'd probably be able to take down the OP in an argument. Or at least would force him to up his game considerable to be able to actually make his points clearly. BTW, I really like your use of "steelmanning" here. Actually looking at his other points after this exchange: (2) I think modern VMs have amazing engineering - is he asking for hacks? Or what? (3) Cloud offerings could be more coherent. But there are real market and organisational constraints. (4) Drag and drop UI designers would be nice, and I miss them, but even the good ones used to produce terrible code when used innocently. (5) I think modern compilers are pretty awesome. Not sure what he wants done. (6) Yeah. We could build better more compact systems. His unhappiness at the state of the world. Hmm. Moaning about it like that doesn't really do much to solve it...

jolux 5y ago

I think having to manually annotate C headers with extra type information starts to reduce the benefits of automatically generating FFI interfaces. Rust already has bindgen which goes pretty far.

nixpulvis 5y ago

Did you just imply that we put the comments of C headers into our types?! Comments are lower than whitespace as far as the compiler should be sure. As I'm sure you are aware https://github.com/rust-lang/rust-bindgen https://github.com/rust-lang/rust-bindgen does basically what you want. I'm actually quite curious where exactly rust-bindgen falls short in the eyes of the author. I'm not as familiar with the other FFI libraries the OP linked.

DonHopkins 5y ago
When is SWIG finally going to support Generalized Whitespace Overloading in C++ 2000? It's been 23 years, 2 months, and 19 days since the technical details were published in AT&T Labs Technical Report no. 42! https://www.stroustrup.com/whitespace98.pdf https://www.stroustrup.com/whitespace98.pdf

masklinn 5y ago

> All we'd need is comments in header files with the extra type information encoded, and automated FFI would be possible. That’s SWIG. It’s something like 15 years old, possibly more. > building a type system on top of a language that lacks it is anything but easy, but it's possible. TypeScript is an excellent example. That has nothing to do with the issue at hand. You can compile haskell to c, that does not help FFI-ing to unannotated C functions.

DonHopkins 5y ago
https://en.wikipedia.org/wiki/SWIG https://en.wikipedia.org/wiki/SWIG >Initial release February 1996; 25 years ago http://www.swig.org/history.html http://www.swig.org/history.html >July, 1995. Dave develops SWIG while working in the Theoretical Physics Division at Los Alamos National Laboratory. Originally, it was conceived as an extension building tool for a customized scripting language that had been created for the Connection Machine 5. David Beazley, the author of SWIG, is a brilliant programmer, mad scientist, and excellent presenter. https://en.wikipedia.org/wiki/David_M._Beazley https://en.wikipedia.org/wiki/David_M._Beazley https://www.dabeaz.com/ https://www.dabeaz.com/ Check out his many talks about programming, especially his epic PyCon 2014 talk on his work as an expert on a patent infringement case. https://www.youtube.com/user/dabeazllc/videos https://www.youtube.com/user/dabeazllc/videos https://www.youtube.com/watch?v=RZ4Sn-Y7AP8 https://www.youtube.com/watch?v=RZ4Sn-Y7AP8 >David Beazley: Discovering Python - PyCon 2014 >So, what happens when you lock a Python programmer in a secret vault containing 1.5 TBytes of C++ source code and no internet connection? Find out as I describe how I used Python as a secret weapon of "discovery" in an epic legal battle. >Slides can be found at: https://speakerdeck.com/pycon2014 https://speakerdeck.com/pycon2014 and https://github.com/PyCon/2014-slides https://github.com/PyCon/2014-slides