On Tuesday, 15 March 2016 at 19:59:01 UTC, deadalnix wrote:
On Tuesday, 15 March 2016 at 11:47:20 UTC, ZombineDev wrote:
Instead I think that if we improve D's existing introspection
capabilities and expose the compiler as a library at
compile-time, we will have a much powerful system than any
potential macro system, for a fraction of the complexity.
These videos are what changed my mind:
1. https://www.youtube.com/watch?v=OHZwYYW9koI
2. https://www.youtube.com/watch?v=59lKAlb6cRg
(Jonathan Blow's programming language for games)
It is like one of these simili good idea that everybody tries
and everybody regrets it. You DON'T want to expose your
compiler implementation to the language.
Jonathan Blow is certainly a talented person, but he has a very
grave NIH syndrome and various blind spot in language design.
Well I agree with most of what you said. While I was watching his
videos, I could't stop thinking "but you can already do this in
D" about a lot of the stuff he "invented".
On the other hand, his videos are quite interesting, especially
considering he has no PL design/compiler background. I like that
he takes some ideas to the extreme. I'm certain that if he didn't
have such strong NIHS, it would have taken him years to get same
results with D.
Pointers with ownership semantics, SoA/AoS, purely CTFE-based
build system, compiler message loop, etc. are are all very
powerful things (as he demonstrates), and sadly I don't see them
comming to D in the near future, so it's good that he decided to
pursue them, so we can see if they're worthwhile exploring for D.
An interface to the compiler is not the same as exposing the
internels of the implementation. If you're skeptical about
robustness or scalability of such system, I will point out this
access can restricted to certain well-defined places (maybe
something similar to shared static this()). But certainly his
direction game-changing if not game-enabling (to quote Andrei).
