2 ms·

yeah they went the fast and cheap route instead of doing the right thing, and they are now going to be bitten by it, and they can go cry a river for all that I

yeah they went the fast and cheap route instead of doing the right thing, and they are now going to be bitten by it, and they can go cry a river for all that I care. those are the sloppy engineers that are holding back evolution of software at large, from little things like obscure functions to huge operating systems like http://blogs.msdn.com/b/oldnewthing/archive/2005/07/28/444390.aspx http://blogs.msdn.com/b/oldnewthing/archive/2005/07/28/44439...

Someone1234 11y ago
You forgot to explain what the "right thing" that they should be doing is? Even according to most articles on the topic there is very to any pleasant alternatives that are cross platform e.g. https://dzone.com/articles/understanding-sunmiscunsafe https://dzone.com/articles/understanding-sunmiscunsafe
- LoSboccacc 11y ago
  jni, and don't tell me now that c isn't portable.
  - Someone1234 11y ago
    C isn't portable. You cannot write it once and run it everywhere, each platform needs a bunch of macros and flags. Plus you'll now either be delivering it in binary form (which may or may not work due to bitness, OS incompatibilities, and so on) or you'll be delivering it as code (which may or may not work due to compiler incompatibilities, build system components available, and missing libraries). C is only portable in the sense that "every platform ever made has a C compiler." But if you've ever written a C application which is just meant to run on Windows, OS X, and Linux you'll know that it is a painful experience (double that if they're meant to compile it themselves).
    - LoSboccacc 11y ago
      *bad C isn't portable. and you can pack as many platform as you wish in your binary distribution, so single download still works everywhere (everywhere you built beforehand).
      - ectoplasm 11y ago
        I think the issue is a disagreement over what portability means. To me, portability doesn't mean write once, run everywhere, it just means you can make it run on a different platform with a bit of effort. In a C/C++ program, if you're careful, you can isolate the platform-independent parts so that you only have to write them once. VM languages abstract further by creating a new language for these platform-independent parts. However, the platform-dependent parts are still going to be written in C/C++, or assembly, or generated by a JIT compiler written in C/C++ (there are rare exceptions). So if anything, I would say that C/C++ enables portability, simply because there aren't any other viable choices besides assembly when it comes to generating platform-specific machine code.
        LoSboccacc 11y ago
        no the issue is that while it's true that complex library accessing native stuff in c are hard to port, you don't need the whole stuff ported under jni, and here is the missing link, the functionality provided by unsafe is limited enough (think of it as a building block for higher level stuff) that it could be reasonably done in c, using posix stuff and some patching in for window which while non posix enough is at least stable trough versions. so it basically become write twice run on many things, which is good enough. the problem is that it's not 'rewrite all the libraries in jni' but only 'rewrite the two calls you need in jni' - scoping is relevant, as we are not arguing about jni in a vacuum.

Someone1234 11y ago

You forgot to explain what the "right thing" that they should be doing is? Even according to most articles on the topic there is very to any pleasant alternatives that are cross platform e.g. https://dzone.com/articles/understanding-sunmiscunsafe https://dzone.com/articles/understanding-sunmiscunsafe

LoSboccacc 11y ago
jni, and don't tell me now that c isn't portable.
- Someone1234 11y ago
  C isn't portable. You cannot write it once and run it everywhere, each platform needs a bunch of macros and flags. Plus you'll now either be delivering it in binary form (which may or may not work due to bitness, OS incompatibilities, and so on) or you'll be delivering it as code (which may or may not work due to compiler incompatibilities, build system components available, and missing libraries). C is only portable in the sense that "every platform ever made has a C compiler." But if you've ever written a C application which is just meant to run on Windows, OS X, and Linux you'll know that it is a painful experience (double that if they're meant to compile it themselves).
  - LoSboccacc 11y ago
    *bad C isn't portable. and you can pack as many platform as you wish in your binary distribution, so single download still works everywhere (everywhere you built beforehand).
    - ectoplasm 11y ago
      I think the issue is a disagreement over what portability means. To me, portability doesn't mean write once, run everywhere, it just means you can make it run on a different platform with a bit of effort. In a C/C++ program, if you're careful, you can isolate the platform-independent parts so that you only have to write them once. VM languages abstract further by creating a new language for these platform-independent parts. However, the platform-dependent parts are still going to be written in C/C++, or assembly, or generated by a JIT compiler written in C/C++ (there are rare exceptions). So if anything, I would say that C/C++ enables portability, simply because there aren't any other viable choices besides assembly when it comes to generating platform-specific machine code.
      - LoSboccacc 11y ago
        no the issue is that while it's true that complex library accessing native stuff in c are hard to port, you don't need the whole stuff ported under jni, and here is the missing link, the functionality provided by unsafe is limited enough (think of it as a building block for higher level stuff) that it could be reasonably done in c, using posix stuff and some patching in for window which while non posix enough is at least stable trough versions. so it basically become write twice run on many things, which is good enough. the problem is that it's not 'rewrite all the libraries in jni' but only 'rewrite the two calls you need in jni' - scoping is relevant, as we are not arguing about jni in a vacuum.