> really-bad compile-time languages (called "type systems") that do 5% of what's useful with incomprehensible syntax, rather than just make the compiler itself programmable.
Because some things aren't knowable at compile time. E.g. what is the value I enter at runtime, and all values derived from it, but also state of environment, and so on.
Pretending they are the same is a weak point of Zig. By making `const` a property determined by the compiler, you can accidentally introduce breaking changes, just by changing function contents.
I wasn't talking just about Zig's implementation of comptime, I was talking about collapsing the distinction between compiler and program -- if done well then the problems mentioned in that article need not occur.
I think the key feature here is making compilation a program that you write wherein you can fully introspect your program. Worries here about IDE support fadeaway, as the full state of the compiler is available -- if some annotations on code are required to guide IDEs, so be it.
I wasnt saying that type systems should be replaced with compile-time programs, only that they are compile time programs, and often really bad ones. (My claim: Programmers shouldnt only have the type system to program the compiler.)
Better that the type system be extremely simple and let the programer transform their program as they wish.
Separation of compile vs runtime is as useful as separations between pure and non-pure functions. Pretending they are the same will lose you information.
Sounds to me you just want Lisp or Smalltalk (self modifications galore, no difference between compile and runtime, small syntax).
I think you are making more of a distinction between optimizations and runtime, not compilation. Doing compilation is about taking a lot of arbitrary user-input (in the form of urls and cmake files and code edits) and executing that. Then optimization occurs which is a lot of pure transforms. Then runtime occurs, which is when the program takes a lot of user-input again. But step one usually is in a different language than step three, which is extra effort to learn. And step 2 doesn’t really need to visible to users, since it is pure the user doesn’t really need to directly see the side effects from that.
Because some things aren't knowable at compile time. E.g. what is the value I enter at runtime, and all values derived from it, but also state of environment, and so on.
Pretending they are the same is a weak point of Zig. By making `const` a property determined by the compiler, you can accidentally introduce breaking changes, just by changing function contents.
https://typesanitizer.com/blog/zig-generics.html