On Monday, 19 April 2021 at 08:46:05 UTC, Ola Fosheim Grøstad
wrote:
I think the downsides are conceptual and technical, not social.
If you can implement a version counter then you get all kinds
of problems, like first compilation succeeding, then the second
compilation failing with no code changes. Also, you can no
longer cache intermediate representations between compilations
without a rather significant additional machinery. It is better
to do this in a more functional way, so you can generate a
file, but it isn't written to disk, it is an abstract entity
during compilation and is turned into something concrete after
compilation.
So, anything that can be deduced from the input is fair game,
but allowing arbitrary I/O is a completely different beast,
compilation has to be idempotent. It should not be possible to
write a program where the first compilation succeeds and the
second compilation fails with no code changes between the
compilation executions. Such failures should be limited to the
build system so that you can quickly correct the problem.
IMHO, a good productive language makes debugging easier, faster
and less frequently needed. Anything that goes against that is
a move in the wrong direction.
Right, I agree with all of this. I just think the way to get to
it is to first allow everything, and then in a second step pare
it down to something that does what people need while also being
monitorable. This is as "simple" as merging every IO call the
program does into its state count.
(For my lang, I just go and hash every part of the program during
compilation. So caching works on the basis of what actually goes
into the binary.)
But my view is, you have those issues anyways! You need to run a
caching dub server, and you need to run it on a Docker image, and
you need to pretty much mirror every upstream package that your
Docker install pulls in, *anyways.* You can't escape the vagaries
of the build environment changing under you by limiting the
language. And everything you keep out of the language - IO,
downloads, arbitrary commands whose output is relevant - the rest
of your build environment usually does regardless. (And it will
mess you up at the first, slightest provocation. Bloody Ubuntu
and its breaking changes in patch releases...) So my view is the
other way around - make the language the single point of contact
for *all of that stuff*, make CTFE powerful enough to hash static
libraries and process header files live during compilation, so
you can pull as much of the complexity as possible into the
controlled environment of the compiler. And then when you know
what you need there, take a step back and frameworkize it, so you
can do change detection inside your single build system. You
can't get the entire OS on board, but you can maybe get all or
most of your language library developers on board.
Anyways, even agreeing that you're right, "look, we tried it and
it didn't work, in fact it was a disaster, see discussions here
and here, or download version 2019-03-06 nightly to try how it
went" is just inherently a stronger argument.
to find out what works and what doesn't, and you can't gather
experience with what people actually want to do and how it
works in practice if you lock things down from the start. In
That's ok for a prototype, but not for a production language.
I think most long-term successful languages straddle a line here.
For instance, looking at Rust, the use of nightly and stable
channels allows the language to experiment while also keeping a
guarantee that once it commits to a feature enough to merge it
into stable, it won't change "overnight". D is trying to do a
similar thing with DIPs and preview flags and deprecations, but
the jury's still out on how well it's working - or if not, if D
can make it work. At any rate, with a lot of features like
implicit conversions, I think people would find that they're
harmless and highly useful if they'd just try them for a while.
