4 ms·

I have only glossed over the paper (yet), but this raises some thoughts on C in general. Why/Where/How we use it. I could distinguish 5 distinct use cases for C

I have only glossed over the paper (yet), but this raises some thoughts on C in general. Why/Where/How we use it. I could distinguish 5 distinct use cases for C: 1. Legacy code 2. Shared (closed) code 3. Zero runtime dependency code 4. Hardware control 5. Resource limitations This could be a good thing for (1.) - rewriting a project (most) in a safe language is just infeasible, yet this offers some guarantees/protection basically for free. Even if a tool (any tool) catches fire all over the place on first run because of a bug (in app code) it's still a good thing. Sometimes we want to share some functionality (library), yet stay closed source. Or have an ability to take a file, drop it on a remote machine and expect it to run. This is what native binaries with a stable API are for. Yet calling foreign function in VM'd languages is often so awkward that we just end up reimplementing a lot of software instead of calling foreign function possibly shipped/managed at an OS level. By hardware control I mean something like writing to 0xABAD1DEA and having data fly out of serial port or NIC change modes or something along those lines. I guess this is doable in managed languages by some built-in magic proxy object, but I'm not entirely sure if this does not start with "write hardware definition file and rebuild the VM". Just a thought. 5. is the basic idea why I'm attempting to discuss this. Small MCUs are still general purpose computers, just very limited, and are rather good litmus tests - is it possible to cram a Hello World into ATtiny with 512 bytes of memory? Is it possible to run something on baremetal ARM Cortex M3/4 (no FPU, MPU/MMU)? No? Then it is by no means "general purpose" and we should thoroughly discuss limitations imposed by the technology. Programming is a discipline just too diverse for a single individual to grasp and too rarely we step outside our boxen to see the whole world.

iofj 11y ago
For legacy code a converter might be the better option. E.g. http://www.tangiblesoftwaresolutions.com/Product_Details/CPlusPlus_to_Java_Converter_Details.html http://www.tangiblesoftwaresolutions.com/Product_Details/CPl... Yes, it's not perfect but at least debugger, instrumentation, ... will work against the module.
- friendzis 11y ago
  Well... If you just want to take old abandoned source and somehow run it - anything goes (IIRC, NumPy requires Fortran for MKL). I meant old projects that are still maintained at some level yet are large in scope and cannot be reimplemented incrementally, think OpenSSL. If we are talking about e.g. servers, we can safely assume pretty beefy x86-compatible hardware and discuss in the context of that. In my book C is the ultimate at general-purposeness and anything we attempt to do with C must be discussed in that light.
nanofortnight 11y ago
6. As an intermediate/output language for a compiler.
vidarh 11y ago
An example of where this might be useful is e.g. jRuby (Chris, one of the authors of this paper, and whose site this is linked to, worked on the Truffle backend for jRuby) - there are tons of Ruby gems out there with extensions written in C. I supposed this fits in the "legacy" category, of sorts, though for MRI this is not "legacy" but an artefact of the large number of C libraries people want to interface with coupled with performance considerations vs. MRI. In general the large number of Gems with C extensions is a bit of a pain point for alternative Ruby implementations. I'd imagine there are quite a few other similar situations where you're running code on the JVM but it would be convenient to be able to pull in some C code without having to deal with JNI etc.

iofj 11y ago

For legacy code a converter might be the better option. E.g. http://www.tangiblesoftwaresolutions.com/Product_Details/CPlusPlus_to_Java_Converter_Details.html http://www.tangiblesoftwaresolutions.com/Product_Details/CPl... Yes, it's not perfect but at least debugger, instrumentation, ... will work against the module.

friendzis 11y ago
Well... If you just want to take old abandoned source and somehow run it - anything goes (IIRC, NumPy requires Fortran for MKL). I meant old projects that are still maintained at some level yet are large in scope and cannot be reimplemented incrementally, think OpenSSL. If we are talking about e.g. servers, we can safely assume pretty beefy x86-compatible hardware and discuss in the context of that. In my book C is the ultimate at general-purposeness and anything we attempt to do with C must be discussed in that light.

nanofortnight 11y ago

6. As an intermediate/output language for a compiler.

vidarh 11y ago

An example of where this might be useful is e.g. jRuby (Chris, one of the authors of this paper, and whose site this is linked to, worked on the Truffle backend for jRuby) - there are tons of Ruby gems out there with extensions written in C. I supposed this fits in the "legacy" category, of sorts, though for MRI this is not "legacy" but an artefact of the large number of C libraries people want to interface with coupled with performance considerations vs. MRI. In general the large number of Gems with C extensions is a bit of a pain point for alternative Ruby implementations. I'd imagine there are quite a few other similar situations where you're running code on the JVM but it would be convenient to be able to pull in some C code without having to deal with JNI etc.