Silicon Valley D Meetup - April 15, 2021 - "Compile Time Function Execution (CTFE)"

[Ola Fosheim Grøstad]

On Monday, 19 April 2021 at 09:06:17 UTC, FeepingCreature wrote:
> 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.

I am not saying it is wrong for a new language to try out this 
philosophy, assuming you are willing to go through a series of 
major revisions of the language. But I think for a language where 
"breaking changes" is a made a big deal of, you want to stay 
conservative.

In that regard, I agree it would be social, as in, if you clearly 
state upfront that your new language will come in major versions 
with major breakage at regular intervals then you should have 
more freedom to explore and end up with something much better. 
Which is not necessarily a deal breaker if you also support 
stable versions with some clear time window, like "version 2 is 
supported until 2030".

So, yeah, it is possible. But you have to teach the programmers 
of your philosophy and make them understand that some versions of 
the language has a long support window and other versions are 
more short-lived. Maybe make it clear in the versioning 
naming-scheme perhaps.

D's problem is that there is only one stable version, and that is 
the most recent one... that makes changes more difficult. Also, 
there are not enough users to get significant experience with 
"experimental features". What works for C++ when providing 
experimental features, might not work for smaller languages.


> - 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.

A lot of features are harmless on a small scale. Python is a very 
flexible language and you can do a lot of stuff in it that you 
should not do. Despite this it works very well on a small scale. 
However, for Python to work on a larger scale it takes a lot of 
discipline (social constraints in place of technical constraints) 
and carefully chosen libraries etc. The use context matters, when 
discussing what is acceptable and what isn't. As such, people 
might have different views on language features and there might 
be no right/wrong solution.

Implicit conversions is good for custom ADTs, but the interaction 
with overloading can be problematic, so it takes a lot of 
foresight to get it right. A geometry library can benefit greatly 
from implicit conversions, but you can run into problems when 
mixing libraries that overuse implicit conversions... So, it 
isn't only a question of whether implicit conversions is a bad 
thing or not, but how the language limits "chains of conversion" 
and overloads and makes it easy to predict for the programmer 
when looking a piece of code.