3 ms·

The portability category has some non-intuitive results. By that I mean that I think they're wrong, but it's a matter of how you measure "portability". The cri

The portability category has some non-intuitive results. By that I mean that I think they're wrong, but it's a matter of how you measure "portability". The criterion the author uses is: > If you write some software in a particular language, can you copy the compiled program to another computer and expect it to work? I coalesced the two columns the author used because it was "No" for both in the four examples below: > Java No Complex and fragile bundling of a separate runtime (with licensing issues) > C#/F#/.NET No Complex and fragile bundling of a separate runtime (with licensing issues) > Python No Complex and fragile bundling of a separate runtime > Ruby No Complex and fragile bundling of a separate runtime I don't think that's how we generally think about portability. We usually consider installing the runtime as the platform dependent tax you pay to get your compile-once artifacts. Compiled JARs are generally considered portable. .NET Core binaries are generally considered portable. Python and Ruby scripts are generally considered portable. Requiring that the application be portable by only copying the files across (without installing the runtime or platform abstraction layer) isn't representative of how users or even dev ops teams that handle mixed-platform carry programs across platforms in the first place.

throwaway894345 6y ago
A lot of people are getting hung up on the definition of 'portability'. Yes, the author's definition is pretty obviously using a non-standard definition, but the question is whether the concept he's talking about is helpful. And I think it is--I would much rather have a language like Go where cross compiling is trivial and I can just send my colleagues (even my non-technical colleagues!) a binary file compared to having them install the right version of the runtime and the right dependencies (and probably a virtualenv so it doesn't bungle their system) and then the application code. I don't care very much about whether I can run a single set of artifacts on any target if it's burdensome to prepare the target platform--I'd much rather it be trivial to compile a single artifact for the target platform such that it can just run.
- svrb 6y ago
  > Go where cross compiling is trivial If that's the criterion the author is using then I don't understand how Rust got a "no". Rust cross-compiling is also trivial and I can compile on one machine for a completely different one and send only the binary output.
AnimalMuppet 6y ago
There's portability, and there's portability. You can run a jar file on anything that has a JVM. You can run C code on an 8085 microcontroller if you have a cross-compiler and a way to move the file. So C code is portable to a whole world beyond the "mixed-platform" world that you're thinking of. Now, either you care or you don't. If you don't need portability to every CPU made since 1980, then the difference doesn't matter to you, and Java, C#, and such are portable for everything that you want.
- throwaway894345 6y ago
  To be clear, I think TFA is using an altogether different definition. These are all distinct concepts with value in their own right—it’s unfortunate that they’re overloading the same term.
derbOac 6y ago
Python is an interesting case to me because of my major complaints about it is how unportable it is in practice. In theory, sure, a python script should be portable, but in my experience the level of dependency hell involved can be extreme, and it's not uncommon with what I've done to see a developer specify some baroque stack to get something to work. This in fact is one of the reasons I've seen for using things like conda, so that you can create different environments with different versions of different packages for different applications. This just gets worse when you consider the edge cases for things like pypy etc. I'm not saying this to slam python, as I use it, but it's one thing I find attractive about certain other languages (such as those described as more portable in the linked piece). There's a certain honesty about the linked piece that in the very least seems reasonable, even if you disagree with it. As you say, it depends on your idea of "portability."
tetha 6y ago
This becomes even more complex in the case of java, at least I'm the most familiar with java. And yes, at work, we are distributing jar/war-files built on linux to linux and windows targets, and back in the day to solaris as well. BSD has been prototyped as well on a late friday night. That was funny. However, you could use gcj (for java < 1.4? Not sure) to create standalone systems. And apparently, you can throw java at LLVM to get runnable binaries. So maybe java doesn't even need a runtime? And on the other hand, once JNA/JNI comes into play, portability of jar files becomes ... interesting. This is similar to the usual hell of python with C dependencies. All in all, I don't understand the criteria from the article enough to evaluate that knowledge into a statement.

throwaway894345 6y ago

A lot of people are getting hung up on the definition of 'portability'. Yes, the author's definition is pretty obviously using a non-standard definition, but the question is whether the concept he's talking about is helpful. And I think it is--I would much rather have a language like Go where cross compiling is trivial and I can just send my colleagues (even my non-technical colleagues!) a binary file compared to having them install the right version of the runtime and the right dependencies (and probably a virtualenv so it doesn't bungle their system) and then the application code. I don't care very much about whether I can run a single set of artifacts on any target if it's burdensome to prepare the target platform--I'd much rather it be trivial to compile a single artifact for the target platform such that it can just run.

svrb 6y ago
> Go where cross compiling is trivial If that's the criterion the author is using then I don't understand how Rust got a "no". Rust cross-compiling is also trivial and I can compile on one machine for a completely different one and send only the binary output.

AnimalMuppet 6y ago

There's portability, and there's portability. You can run a jar file on anything that has a JVM. You can run C code on an 8085 microcontroller if you have a cross-compiler and a way to move the file. So C code is portable to a whole world beyond the "mixed-platform" world that you're thinking of. Now, either you care or you don't. If you don't need portability to every CPU made since 1980, then the difference doesn't matter to you, and Java, C#, and such are portable for everything that you want.

throwaway894345 6y ago
To be clear, I think TFA is using an altogether different definition. These are all distinct concepts with value in their own right—it’s unfortunate that they’re overloading the same term.

derbOac 6y ago

Python is an interesting case to me because of my major complaints about it is how unportable it is in practice. In theory, sure, a python script should be portable, but in my experience the level of dependency hell involved can be extreme, and it's not uncommon with what I've done to see a developer specify some baroque stack to get something to work. This in fact is one of the reasons I've seen for using things like conda, so that you can create different environments with different versions of different packages for different applications. This just gets worse when you consider the edge cases for things like pypy etc. I'm not saying this to slam python, as I use it, but it's one thing I find attractive about certain other languages (such as those described as more portable in the linked piece). There's a certain honesty about the linked piece that in the very least seems reasonable, even if you disagree with it. As you say, it depends on your idea of "portability."

tetha 6y ago

This becomes even more complex in the case of java, at least I'm the most familiar with java. And yes, at work, we are distributing jar/war-files built on linux to linux and windows targets, and back in the day to solaris as well. BSD has been prototyped as well on a late friday night. That was funny. However, you could use gcj (for java < 1.4? Not sure) to create standalone systems. And apparently, you can throw java at LLVM to get runnable binaries. So maybe java doesn't even need a runtime? And on the other hand, once JNA/JNI comes into play, portability of jar files becomes ... interesting. This is similar to the usual hell of python with C dependencies. All in all, I don't understand the criteria from the article enough to evaluate that knowledge into a statement.