5 ms·

Author here, I cannot vouch for exactly the competency level here, but I was paraphrasing a remark Andrew Kelley made in a video discussing Zig. From what I rem

Author here, I cannot vouch for exactly the competency level here, but I was paraphrasing a remark Andrew Kelley made in a video discussing Zig. From what I remember he said that many told him that running code at compilation time wasn't a good idea and you shouldn't do it. My understanding was that these must have been people with some experience with programming language design. Why would Andrew Kelley listen to random opinionated guys on the internet? I will try to lookup this video when I have time. I was a bit surprised that this remark was a such a turn-off. Had I known, I should have looked up the video to get the exact quote. It was just meant as a bit of a funny dramatic entry to discussing an unusual language design choice for a statically type language. Sure we are seeing more things like const expressions in C++ today, but at the time this wasn't very common.

belmarca 4y ago
I don't think it's such a big issue but it is quite surprising to read, since these concepts have been known and used for many decades :)
- coldtea 4y ago
  I don't think that the precedent matters that much in this situation, as to whether people would dismiss such an idea or not. People can dismiss language ideas and concepts that "have been known and used for many decades" just the same. For a trivial example: significant whitespace. So, e.g. "Lisp has had that since forever" is not a guarantee people would be OK with it, unless they also like Lisp - not to mention they might not even know about it in Lisp. As for C++, many people consider templates - at least as implemented - a bad idea. So some people knowing that it existed in C++ already, and considering it a bad idea to have in Zig is not contradictory.
  - FeepingCreature 4y ago
    Sure but then it's like... for example, if you land rockets and your advertisement says "People told me it couldn't be done!", then fair enough. But if you, say, build an electric car and your advertisement says "People told me it couldn't be done!", then ... who exactly have you been talking to? The phrase "They said it couldn't be done!" is an evocative proxy for technological novelty. If the experts are not representative, the claim of novelty will be misleading.
    - coldtea 4y ago
      yeah, though in this case they didn't say "it can't be done" or "was never done" - just that it is a "really dumb idea". At least that's what the post claims they said.
      - belmarca 4y ago
        Which is precisely my point. As one other commenter said: "who have you been talking to?". Executing code at compile-time is a great idea in general, maybe those experts were talking about a very particular problem? It's not clear.
        coldtea 4y ago
        >Executing code at compile-time is a great idea in general Well, it did create a big mess and overhead in C++ for one (not to mention adding another turing-complete language on top of it)...
        belmarca 4y ago
        Ah but that's an implementation and design choice issue. It's like saying "classes are a bad idea because implementing them in pure C is cumbersome".
        coldtea 4y ago
        Well, to criticize something people start (and, often, end) on concrete examples they've seen it in practice. And for "compile time code generation" C++ templates are an example they'd be familiar with (perhaps the canonical one, as more people know C++ than Lisp).
        deleted 4y ago
        [deleted]
int_19h 4y ago
C++11 constexpr predates Zig by 5 years.
- ctrlmeta 4y ago
  Lisp macros (and earlier FEXPRs) predate Zig by 53 years!
  - bsder 4y ago
    FEXPRs aren't comptime and aren't macros--the point of FEPXRs is that you hold off evaluating the arguments until runtime or, perhaps, not at all (think short circuit booleans). This was actually a schism in Lisp and why FEXPRs died out. CS theory wanted to compile things for speed and FEXPRs very much didn't fit into that. This is why macros took over--they were very much targeted at compile time. The late John Shutt's thesis and work on the language he called Kernel goes into quite a bit of detail and the history about it: https://web.cs.wpi.edu/~jshutt/kernel.html https://web.cs.wpi.edu/~jshutt/kernel.html Sadly, Shutt never really "completed" the Kernel language--the language is very interesting but is extremely slow and unwieldy in the descriptions he gave. It generates a lot of garbage and extra "environments"; it resists compilation and memoization; it sometimes seems to go out of its way to deal with things that make life very difficult (circular and infinite lists). A couple of good passes of optimization might have produced something very interesting. I was personally attracted to it for very small embedded devices (<16K RAM/16K Flash) as it delgates a lot of macrology to interpretation--sadly I just couldn't get the footprint down far enough given all the garbage and environments the language generates. I suspect it's possible, but it would take someone who knew the landscape intimately to figure out what needed to be dropped.
    - klipt 4y ago
      > hold off evaluating the arguments until runtime or, perhaps, not at all (think short circuit booleans). > infinite lists Sounds like an early attempt at Haskell. Haskell is lazy by default so you can write your own "if" as a function and it will be just as short circuiting as the built in if. And infinite lists show up in basic Haskell tutorials. However Haskell combines this laziness with immutability, which is an easier combination to reason about than laziness with mutable side effects. Compiler technology for lazy languages is definitely impressive, but it's still the case that if you want to squeeze the last bit of performance out of Haskell code it does usually require manually forcing eager evaluation.

belmarca 4y ago

I don't think it's such a big issue but it is quite surprising to read, since these concepts have been known and used for many decades :)

coldtea 4y ago
I don't think that the precedent matters that much in this situation, as to whether people would dismiss such an idea or not. People can dismiss language ideas and concepts that "have been known and used for many decades" just the same. For a trivial example: significant whitespace. So, e.g. "Lisp has had that since forever" is not a guarantee people would be OK with it, unless they also like Lisp - not to mention they might not even know about it in Lisp. As for C++, many people consider templates - at least as implemented - a bad idea. So some people knowing that it existed in C++ already, and considering it a bad idea to have in Zig is not contradictory.
- FeepingCreature 4y ago
  Sure but then it's like... for example, if you land rockets and your advertisement says "People told me it couldn't be done!", then fair enough. But if you, say, build an electric car and your advertisement says "People told me it couldn't be done!", then ... who exactly have you been talking to? The phrase "They said it couldn't be done!" is an evocative proxy for technological novelty. If the experts are not representative, the claim of novelty will be misleading.
  - coldtea 4y ago
    yeah, though in this case they didn't say "it can't be done" or "was never done" - just that it is a "really dumb idea". At least that's what the post claims they said.
    - belmarca 4y ago
      Which is precisely my point. As one other commenter said: "who have you been talking to?". Executing code at compile-time is a great idea in general, maybe those experts were talking about a very particular problem? It's not clear.
      - coldtea 4y ago
        >Executing code at compile-time is a great idea in general Well, it did create a big mess and overhead in C++ for one (not to mention adding another turing-complete language on top of it)...
        belmarca 4y ago
        Ah but that's an implementation and design choice issue. It's like saying "classes are a bad idea because implementing them in pure C is cumbersome".
        coldtea 4y ago
        Well, to criticize something people start (and, often, end) on concrete examples they've seen it in practice. And for "compile time code generation" C++ templates are an example they'd be familiar with (perhaps the canonical one, as more people know C++ than Lisp).
        deleted 4y ago
        [deleted]

int_19h 4y ago

C++11 constexpr predates Zig by 5 years.

ctrlmeta 4y ago
Lisp macros (and earlier FEXPRs) predate Zig by 53 years!
- bsder 4y ago
  FEXPRs aren't comptime and aren't macros--the point of FEPXRs is that you hold off evaluating the arguments until runtime or, perhaps, not at all (think short circuit booleans). This was actually a schism in Lisp and why FEXPRs died out. CS theory wanted to compile things for speed and FEXPRs very much didn't fit into that. This is why macros took over--they were very much targeted at compile time. The late John Shutt's thesis and work on the language he called Kernel goes into quite a bit of detail and the history about it: https://web.cs.wpi.edu/~jshutt/kernel.html https://web.cs.wpi.edu/~jshutt/kernel.html Sadly, Shutt never really "completed" the Kernel language--the language is very interesting but is extremely slow and unwieldy in the descriptions he gave. It generates a lot of garbage and extra "environments"; it resists compilation and memoization; it sometimes seems to go out of its way to deal with things that make life very difficult (circular and infinite lists). A couple of good passes of optimization might have produced something very interesting. I was personally attracted to it for very small embedded devices (<16K RAM/16K Flash) as it delgates a lot of macrology to interpretation--sadly I just couldn't get the footprint down far enough given all the garbage and environments the language generates. I suspect it's possible, but it would take someone who knew the landscape intimately to figure out what needed to be dropped.
  - klipt 4y ago
    > hold off evaluating the arguments until runtime or, perhaps, not at all (think short circuit booleans). > infinite lists Sounds like an early attempt at Haskell. Haskell is lazy by default so you can write your own "if" as a function and it will be just as short circuiting as the built in if. And infinite lists show up in basic Haskell tutorials. However Haskell combines this laziness with immutability, which is an easier combination to reason about than laziness with mutable side effects. Compiler technology for lazy languages is definitely impressive, but it's still the case that if you want to squeeze the last bit of performance out of Haskell code it does usually require manually forcing eager evaluation.