5 ms·

Portability is not black or white. Macros are essentially selecting different code depending on the platform. A good high-level language would not need to do th

Portability is not black or white. Macros are essentially selecting different code depending on the platform. A good high-level language would not need to do this.

vasco 9y ago
Just because you don't see those ugly macros to make your pure high level language portable, doesn't mean they're not there, somewhere.
- reikonomusha 9y ago
  Yes but this is a separation of concerns. This is precisely the point of an abstraction, especially at the level of a language and its implementations. Writing code in Common Lisp means you're writing something with semantics promised by the Common Lisp specification. Vendors implement the spec (perhaps using nasty #ifdefs), and developers write code against the spec. The spec is a contract, and from the point of view of the programmer, it's indifferent to platform change and so on (up to what the spec says is platform-dependent, like machine integer size or maximum array length). Just because a particular implementation may not be considered portable, doesn't mean my program (which I may choose to run on that implementation) isn't portable.
  - daemin 9y ago
    Unfortunately the architectural details of the machine will leak through to the program you are writing, and you will need to twist your code in order to get correct behaviour and fast execution. Case in point is the recent article posted on HN about the platform specific details of getTimeMilliseconds() in Java.
    - tpxl 9y ago
      Could you link that article? I searched and couldn't find it on hN.
      - daemin 9y ago
        I believe the article was http://pzemtsov.github.io/2017/07/23/the-slow-currenttimemillis.html http://pzemtsov.github.io/2017/07/23/the-slow-currenttimemil... Although I couldn't easily find it in my history or on HN. I had to resort to the Googles.
  - junke 9y ago
    Sticking to the spec is one way to be portable. Building a portability layer is another one; this is how Common Lisp grows, by taking advantage of the work of different implementations and using standardized tools (FEATURES, reader conditionals) to build a common interface. See e.g. CFFI which has become the (defacto) standard for loading C libraries (https://common-lisp.net/project/cffi/spec/cffi-sys-spec.html#Introduction https://common-lisp.net/project/cffi/spec/cffi-sys-spec.html...).
- willtim 9y ago
  It's called abstraction. It's a good thing when trying to build correct software.
- christopheml 9y ago
  The issue here is handling portability yourself or let the language and its toolchain do it. The odds that you are doing a better job than the community to handle portability are pretty low right from the start and they get lower and lower if the laguage is well-supported. My "ugly macros" are tested against my own implementation only. Compiler's are tested against thousands.
- _Codemonkeyism 9y ago
  The difference is: Do I have to write the code to make it portable or does the language developers write that code.

Portability is not black or white. Macros are essentially selecting different code depending on the platform. A good high-level language would not need to do this.

vasco 9y ago

Just because you don't see those ugly macros to make your pure high level language portable, doesn't mean they're not there, somewhere.

reikonomusha 9y ago
Yes but this is a separation of concerns. This is precisely the point of an abstraction, especially at the level of a language and its implementations. Writing code in Common Lisp means you're writing something with semantics promised by the Common Lisp specification. Vendors implement the spec (perhaps using nasty #ifdefs), and developers write code against the spec. The spec is a contract, and from the point of view of the programmer, it's indifferent to platform change and so on (up to what the spec says is platform-dependent, like machine integer size or maximum array length). Just because a particular implementation may not be considered portable, doesn't mean my program (which I may choose to run on that implementation) isn't portable.
- daemin 9y ago
  Unfortunately the architectural details of the machine will leak through to the program you are writing, and you will need to twist your code in order to get correct behaviour and fast execution. Case in point is the recent article posted on HN about the platform specific details of getTimeMilliseconds() in Java.
  - tpxl 9y ago
    Could you link that article? I searched and couldn't find it on hN.
    - daemin 9y ago
      I believe the article was http://pzemtsov.github.io/2017/07/23/the-slow-currenttimemillis.html http://pzemtsov.github.io/2017/07/23/the-slow-currenttimemil... Although I couldn't easily find it in my history or on HN. I had to resort to the Googles.
- junke 9y ago
  Sticking to the spec is one way to be portable. Building a portability layer is another one; this is how Common Lisp grows, by taking advantage of the work of different implementations and using standardized tools (FEATURES, reader conditionals) to build a common interface. See e.g. CFFI which has become the (defacto) standard for loading C libraries (https://common-lisp.net/project/cffi/spec/cffi-sys-spec.html#Introduction https://common-lisp.net/project/cffi/spec/cffi-sys-spec.html...).
willtim 9y ago
It's called abstraction. It's a good thing when trying to build correct software.
christopheml 9y ago
The issue here is handling portability yourself or let the language and its toolchain do it. The odds that you are doing a better job than the community to handle portability are pretty low right from the start and they get lower and lower if the laguage is well-supported. My "ugly macros" are tested against my own implementation only. Compiler's are tested against thousands.
_Codemonkeyism 9y ago
The difference is: Do I have to write the code to make it portable or does the language developers write that code.