4 ms·

Relying on a macro processor to patch and bandage your program at compile time depending on a collection of symbolic features isn't really representative of por

Relying on a macro processor to patch and bandage your program at compile time depending on a collection of symbolic features isn't really representative of portability of a language and your code. To me, that is brute forcing portability, and is a web of conditional inclusions/exclusions that needs to be maintained and added to per-architecture and per-OS. Something that is, in some sense, truly portable is one that has a single specification that runs on all platforms the base implementation supports. Virtual machines and certain styles of language standard are often able to accomplish portability for a vast number of applications.

SmallDeadGuy 9y ago
I would argue the other way. Something which requires a base implementation to be installed on a system which generates different machine code based on a single specification is less portable than a macro processor generating different versions of a program. Sure, people will have had something like python installed since a long time ago, but a new setup requires downloading 2 objects (the base implementation and the program) compared to a single one (a platform-specific copy of a program).
- reikonomusha 9y ago
  You still need to download two objects: the C code and the C compiler, even if the C code has already been processed. Edit: Not to mention libc, libm, and the like.
  - SmallDeadGuy 9y ago
    You don't need a C compiler to run an already compiled program. You may need libraries, just like almost every language, but only the developer needs to download the compiler and not every single user. It gives options to the developer to target multiple platforms without extra effort from the users of those platforms.
- willtim 9y ago
  How is the deployment of a high-level runtime different from libc? Both can be statically-linked if required.
majewsky 9y ago
> Relying on a macro processor [...] isn't really representative of portability of a language and your code. I would argue that the C preprocessor is, for all intents and purposes, part of the C language. C is not quite practical without its preprocessor, and the preprocessor is not quite practical with any language other than C (or a derivative like C++).
- reikonomusha 9y ago
  The preprocessor does not add portability. It adds a path for you, the programmer, to succinctly specify additions and deletions from your program so as to make it portable. This is markedly different from a language that, for example, guarantees the existence of integers of unbounded size. In this case, when working with integers, we make no mention of the platform to execute on. We are provided with an abstract guarantee that one can rely on regardless of the concrete platform.

SmallDeadGuy 9y ago

I would argue the other way. Something which requires a base implementation to be installed on a system which generates different machine code based on a single specification is less portable than a macro processor generating different versions of a program. Sure, people will have had something like python installed since a long time ago, but a new setup requires downloading 2 objects (the base implementation and the program) compared to a single one (a platform-specific copy of a program).

reikonomusha 9y ago
You still need to download two objects: the C code and the C compiler, even if the C code has already been processed. Edit: Not to mention libc, libm, and the like.
- SmallDeadGuy 9y ago
  You don't need a C compiler to run an already compiled program. You may need libraries, just like almost every language, but only the developer needs to download the compiler and not every single user. It gives options to the developer to target multiple platforms without extra effort from the users of those platforms.
willtim 9y ago
How is the deployment of a high-level runtime different from libc? Both can be statically-linked if required.

majewsky 9y ago

> Relying on a macro processor [...] isn't really representative of portability of a language and your code. I would argue that the C preprocessor is, for all intents and purposes, part of the C language. C is not quite practical without its preprocessor, and the preprocessor is not quite practical with any language other than C (or a derivative like C++).

reikonomusha 9y ago
The preprocessor does not add portability. It adds a path for you, the programmer, to succinctly specify additions and deletions from your program so as to make it portable. This is markedly different from a language that, for example, guarantees the existence of integers of unbounded size. In this case, when working with integers, we make no mention of the platform to execute on. We are provided with an abstract guarantee that one can rely on regardless of the concrete platform.