Super-dee-duper D features

[janderson]

Nicolai Waniek wrote:
Nicolai Waniek wrote:
> janderson wrote:
>> What about using it for files that you are going to load at runtime
>> otherwise? XML ect...?
>>
>> -Joel
> 
> Loading the file belongs to runtime. Well, if it would take 10 minutes
> to load the file instead of 1 second if it was "loaded during
> compilation", that would be an argument for something like that - but I
> guess this won't be the case in most projects.
> 
> With your example: If you define something like that for compile time,
> it won't make it possible to change this dynamically, e.g. with a
> configuration file. If you write a super-D-duper library that loads file
> xyz and converts it to zyx, you won't want to sell the code (if it's not
> open source) so this possibility won't even fit to your business...
> 
> So, if "a" stands for "easy to learn, easy to use, fixed language" and
> "b" for "hard to learn because of dynamic language extension" you might
> get something like this for "not using mixins and that kind of stuff":
> 
> a [---|-----------] b
> 
> and the following, if you use them:
> 
> a [----------|----] b
> 
> Well I have to admit that there are some real good and well thought-out
> examples on how to reasonably use the new language features, but there
> will be more examples on how to _not_ use them. and the latter ones will
> be the ones with which we will have to struggle - and I don't want to
> struggle when programming, it usually is a joy! (and that's why I don't
> want to code in C++).

> janderson wrote:
>> What about using it for files that you are going to load at runtime
>> otherwise? XML ect...?
>>
>> -Joel
> 
> Loading the file belongs to runtime. Well, if it would take 10 minutes
> to load the file instead of 1 second if it was "loaded during
> compilation", that would be an argument for something like that - but I
> guess this won't be the case in most projects.
> 
> With your example: If you define something like that for compile time,
> it won't make it possible to change this dynamically, e.g. with a
> configuration file. If you write a super-D-duper library that loads file
> xyz and converts it to zyx, you won't want to sell the code (if it's not
> open source) so this possibility won't even fit to your business...
> 
> So, if "a" stands for "easy to learn, easy to use, fixed language" and
> "b" for "hard to learn because of dynamic language extension" you might
> get something like this for "not using mixins and that kind of stuff":
> 
> a [---|-----------] b
> 
> and the following, if you use them:
> 
> a [----------|----] b
> 
> Well I have to admit that there are some real good and well thought-out
> examples on how to reasonably use the new language features, but there
> will be more examples on how to _not_ use them. and the latter ones will
> be the ones with which we will have to struggle - and I don't want to
> struggle when programming, it usually is a joy! (and that's why I don't
> want to code in C++).

My point is that you shouldn't have to fight if its made as simple as 
run-time.

-Joel