Why are some languages called platform dependent if I can always share the source code?

can always be achieved (even in "platform dependent" languages like C) by sharing the source code which the new machine's compiler will use to compile the machine language code specific to that platform

This is only true for the very simplest programs. The problem is that as soon as you get into any kind of input or output, or memory, or process management, you'll need to call on services provided by the host operating system.

For example: the standard library for C provides a function fopen() to access a file. fopen() will be available on any platform that supports a standards compliant C compiler, so fopen() would be regarded as platform independent.

Sometimes though you will need more control over the details of file access, and you'll directly call a OS kernel function to get access to the file. Languages like C and C++ allow a programmer to directly call functions provided by the host operating system, but each operating system offers a different collection of functions. On Linux the file access function is called open(). The roughly equivalent function on Windows is called CreateFile(), but it has very different arguments and data structures than open(). If your source code contains a call to CreateFile() and you try to compile it on Linux, the compiler will give you an error telling you that it's never heard of such a function. Thus your program is now platform dependent. Internally, fopen() is calling open() or CreateFile() depending on what platform you are on. The developers who write the C standard library rely on a complex web of build files and pre-processor commands to make sure the correct call gets executed on the correct platform.

VM based languages can only (easily) call functions provided by the VM, and the folks who write the VM go to great lengths to make sure that the VM provides the same set of functions on each platform. Some VM do provide facilities that let you call functions in the host operating system, but once you do that, your program will no longer be platform independent.

When is a language platform independent?

A programming language is only a way to express something in source code in an easy way. As soon as nothing in this expression is platform specific (os or cpu dependent), the langage itself is platform independent.

How the code gets executed, be it byte-code or native machine code is in theory independent of the language, even if some languages are closely coupled to an implementation specification.

So, saying that only languages with byte-codes would be platform independent is completely misleading, since tomorrow a byte-code based implementation could be provided for a language that is usually compiled.

Is a platform independent language implementation the better way?

It all depends on the objectives:

• Sharing platform independent byte-code gives indeed the advantage of an easy distribution at a lower cost. This works only with a platform abstraction layer. As a consequence it cannot not use all the possibilities of the platform’s native layer
• Distributing platform specific binary code across multiple platforms is more complex. There’s more building and testing activities (e.g. to verify also potential portability issues). Customer may need to download several versions for several devices. But it allows for maximal performance for CPU intensive tasks.

Examples and limits of platform independence

Take the example of C:

• it has a platform independent specification that identifies the guaranteed behavior, that allows to create portable platform independent source code, that can be compiled on almost any existing CPU and many micro-controllers. The language is therefore platform independent.
• Of course portability requires some discipline, so not every C code is guaranteed to work on every platform if there is UB or implementation dependent features that are used.

If you think there is too much platform specific behavior in C, or not enough warning messages about the use of such features, take a look at ADA. There is much less compiler choice nowadays, but it’s also the example of a platform independent general purpose language. It was designed from the start for the purpose of platform independent reliable software, but with platform specific compilers.

Take the typical example of Pascal. This is the proof that any platform independent language could be implemented with bytecode, if there would be a will:

• 50 years ago, Pascal was invented. It was a platform independent language, with compilers on several platforms.
• 40 years ago, UCSD pascal was released, with a portable p-code, the ancestor of the bytecodes. The fact of being able to run the same p-code on a large set of computers was the state of the art portability. But with the old cpus it was slow. And when more modern cpu architectures got larger integers, it appeared that the p-code was not so portable after all, since it was designed for 16 bits machines (yes, it was state if the art hardware in those time).
• Finally, performance and cheap prices brought back compiled (turbo-) pascal

Bytecode really started to fly with the JVM 25 years ago. The concept was inspired from the p-code. But it was a better time. First more powerful CPU allowed faster processing of bytecode. Second, and more important, the JIT compiling technology finally bridged the performance gap.

Most modern general purpose languages are specified to be platform independent, in that they do not rely on OS specific functions, or cpu architecture. It is true that there is a strong trend nowadays to specify the language implementation using some VM. But the existence of of a VM does not make its bytecode future proof to exploit architectures not yet invented.

And finally most programs are only useful with a nice UI and it’s very difficult to design platform independent UI in such a rich and evolutive domain as native UI, not to speak about integration of innovations that appear faster than language committees can process them (e.g. Voice Based Interfaces and alike). This makes a lot of code less platform independent than it could be, even with platform independent languages.