4 ms·

why is the "payment processing" software written in c/c++ and not something like java in the first place? i would imagine not needing to care too much about mem

why is the "payment processing" software written in c/c++ and not something like java in the first place? i would imagine not needing to care too much about memory would speed up development velocity. was it before java became popular? i can understand the munitions control software possibly running on a constrained device and not needing very sophisticated memory management (cue the old joke about the "ultimate in garbage collection").

lelanthran 5y ago
> why is the "payment processing" software written in c/c++ and not something like java in the first place? Until recently[1] payment terminals were memory constrained devices. Even right now, a significant portion of payment terminals are constrained (128MB of RAM, slow 32-bit processors). Even though Java was around in 2006, the payment terminals I worked on then ran on 16-bit NEC processors (8088, basically). Even if we aren't looking payment terminals (or any of the intermediaries), there's still a large and not-insignificant class of devices for which anything but C or a reduced set of C++ is possible. Having common libraries (zip, tls, etc) written in C means that those libraries are usable on all devices from all manufacturers. [1] The industry-wide trend right now is a move towards android-based terminals. While this does mean that you can write applications in Java and Kotlin for these terminals, it's still cheaper to port the existing C or C++ codebase to Android and interface via JNI, as that reduces the costs (of which certification is a significant minority). Even right now, there is more portability in writing the EMV transaction logic in plain C because then it can be used from almost anywhere. A team that went ahead and wrote the core payment acquisition logic in Java would find themselves offering a smaller variety of products and will soon get beaten in the market by those manufacturers who packaged the logic up into a C library. Don't underestimate how price-sensitive embedded consumers are. A savings of a few dollars per product can absolutely lead to a really large leg up over the competition.

lelanthran 5y ago

> why is the "payment processing" software written in c/c++ and not something like java in the first place? Until recently[1] payment terminals were memory constrained devices. Even right now, a significant portion of payment terminals are constrained (128MB of RAM, slow 32-bit processors). Even though Java was around in 2006, the payment terminals I worked on then ran on 16-bit NEC processors (8088, basically). Even if we aren't looking payment terminals (or any of the intermediaries), there's still a large and not-insignificant class of devices for which anything but C or a reduced set of C++ is possible. Having common libraries (zip, tls, etc) written in C means that those libraries are usable on all devices from all manufacturers. [1] The industry-wide trend right now is a move towards android-based terminals. While this does mean that you can write applications in Java and Kotlin for these terminals, it's still cheaper to port the existing C or C++ codebase to Android and interface via JNI, as that reduces the costs (of which certification is a significant minority). Even right now, there is more portability in writing the EMV transaction logic in plain C because then it can be used from almost anywhere. A team that went ahead and wrote the core payment acquisition logic in Java would find themselves offering a smaller variety of products and will soon get beaten in the market by those manufacturers who packaged the logic up into a C library. Don't underestimate how price-sensitive embedded consumers are. A savings of a few dollars per product can absolutely lead to a really large leg up over the competition.