4 ms·

For what types of applications do you think it's actually important to use the native language of the OS? After all, non-native languages can have bindings for

For what types of applications do you think it's actually important to use the native language of the OS? After all, non-native languages can have bindings for the OS APIs. In your opinion, what are the drawbacks of mostly avoiding C++ and using one's favorite language, as the GP said?

pyrois 12y ago
If you're developing a fairly complex library for things such as image processing, machine learning, numerics, linear algebra, etc., then I think that C/C++ is the way to go. Most languages have some sort of FFI to interact with C, many are even designed explicitly to work with C (such as Cython). C++ is in a similar situation (though compiler support on esoteric processors such as DSPs is still not quite there yet), and it's fairly easy to get a C-compatible API. If you write your library in Perl, guess what, only people writing Perl will use it. If you write it in Java, well, maybe the Scala folk will wrap it up, or the Jython folk, but you won't get any people writing in Ruby to use it. If you write it in C++, you can provide efficient bindings to any of those languages. For an example, look at FFmpeg or ImageMagick. They are libraries that just _won't die_, no matter how hard people have tried. My god, ImageMagick was written in 1987, and it now has Haskell bindings[0]! The only way to get that sort of longevity (and old code is good code, after all [1]) is to write in language that will outlast the ups and downs of the language or framework du jour, and C and C++ have proven to have that staying power. Yeah, they're terrible; I hate them. But there is a reason to use them. [0] http://hackage.haskell.org/package/imagemagick http://hackage.haskell.org/package/imagemagick [1] http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html
pjmlp 12y ago
- Not able to use the OS vendor tooling which only support the official languages - Another layer to debug (FFI) - Possible loss of performance when crossing the FFI barrier - Loss of productivity, because that cool API isn't available and so one has to write it - Writing drivers, daemons/services, OS plugins, ... One of the reasons I moved from Turbo Pascal to C++, when I started coding on Windows 3.0, was being fed up to write binding libraries by myself. Although I really enjoyed Turbo Pascal back then.
- mwcampbell 12y ago
  I can confirm that writing bindings is a big time sink. One of the biggest projects I've worked on is a Win32 application that's primarily written in Lua. I chose Lua because of the small interpreter and minimal standard library; a project requirement was to keep the download size small. But I spent a lot of time writing my own Lua bindings for Win32 APIs. Maybe that just means I should have used a more mainstream alternative language like Python, but even in Python-based Windows projects, I've sometimes had to drop down to ctypes, Cython, or the like. In recent years I've wondered if I would have been better off using C++ in a modern style, with smart pointers, string and container classes, etc. Then I would have had direct access to all Windows APIs, plus access to all of Microsoft's tools.

pyrois 12y ago

If you're developing a fairly complex library for things such as image processing, machine learning, numerics, linear algebra, etc., then I think that C/C++ is the way to go. Most languages have some sort of FFI to interact with C, many are even designed explicitly to work with C (such as Cython). C++ is in a similar situation (though compiler support on esoteric processors such as DSPs is still not quite there yet), and it's fairly easy to get a C-compatible API. If you write your library in Perl, guess what, only people writing Perl will use it. If you write it in Java, well, maybe the Scala folk will wrap it up, or the Jython folk, but you won't get any people writing in Ruby to use it. If you write it in C++, you can provide efficient bindings to any of those languages. For an example, look at FFmpeg or ImageMagick. They are libraries that just _won't die_, no matter how hard people have tried. My god, ImageMagick was written in 1987, and it now has Haskell bindings[0]! The only way to get that sort of longevity (and old code is good code, after all [1]) is to write in language that will outlast the ups and downs of the language or framework du jour, and C and C++ have proven to have that staying power. Yeah, they're terrible; I hate them. But there is a reason to use them. [0] http://hackage.haskell.org/package/imagemagick http://hackage.haskell.org/package/imagemagick [1] http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html

pjmlp 12y ago

- Not able to use the OS vendor tooling which only support the official languages - Another layer to debug (FFI) - Possible loss of performance when crossing the FFI barrier - Loss of productivity, because that cool API isn't available and so one has to write it - Writing drivers, daemons/services, OS plugins, ... One of the reasons I moved from Turbo Pascal to C++, when I started coding on Windows 3.0, was being fed up to write binding libraries by myself. Although I really enjoyed Turbo Pascal back then.

mwcampbell 12y ago
I can confirm that writing bindings is a big time sink. One of the biggest projects I've worked on is a Win32 application that's primarily written in Lua. I chose Lua because of the small interpreter and minimal standard library; a project requirement was to keep the download size small. But I spent a lot of time writing my own Lua bindings for Win32 APIs. Maybe that just means I should have used a more mainstream alternative language like Python, but even in Python-based Windows projects, I've sometimes had to drop down to ctypes, Cython, or the like. In recent years I've wondered if I would have been better off using C++ in a modern style, with smart pointers, string and container classes, etc. Then I would have had direct access to all Windows APIs, plus access to all of Microsoft's tools.