On Monday, 26 August 2013 at 09:29:18 UTC, Chris wrote:
> I don't agree. I first used D exactly because it is an "all-rounder". For me built-in UTF support was as important a factor as native machine code (performance). The reasons why people would perfer C++ to D are probably habit and convenience. If you've used C++ for years why should you bother to learn D? After all, C++ is well established, well-documented, has loads of libraries, will get you a job more eaily etc. Language features and performance are sometimes over-estimated when it comes to analyzing why a language succeeded. There's convenience, marketing (propaganda) etc etc.
>
> Also I don't think that performance alone decides whether a language becomes popular or not. If it were soley down to performance we wouldn't have Java or Python or even Objective-C (which used to be criticized for being too slow). Ease of use, a clear and consistent structure and "write once run everywhere" are very important too. Especially now that developers have to face so many different platforms (Linux, Mac, Windows, Android, iOS) everythnig goes into the direction of "write once ..." That's one of the reasons why Android took off, I think, because developers said "Great, maybe this will put an end to the mobile platform jungle. We'll support Android, less headaches for us!".

I'm trying to analyze the problem from a strategic point of view. For this, I like to invoke the Serenity Prayer (please forgive any distasteful theology):

"God, grant me the serenity to accept the things I cannot change,
The courage to change the things I can,
And wisdom to know the difference."

So yeah, you can't control people's choices. The question is, of the things which *can* be done, is it better to focus on well-roundedness, or to press an advantage where one is already ahead of the pack? Which will lead to greater adoption of the language?

One thing about performance in particular is that it's easy to measure and easy for the naive person to understand what it is. So there is perhaps a risk of being seduced into sacrificing other things which are more subtle, but equally important, in favor of winning at performance. Yet I think the key point is that that's not going to happen here. I personally have too much respect for the engineers working on this thing to think they would be that short-sighted.

But if it's *possible* to grab a performance trophy while still keeping the other flocks well-fed, it seems like a clear strategic win.

On Monday, 26 August 2013 at 18:33:55 UTC, Zach the Mystic wrote:
> On Monday, 26 August 2013 at 09:29:18 UTC, Chris wrote:
>> I don't agree. I first used D exactly because it is an "all-rounder". For me built-in UTF support was as important a factor as native machine code (performance). The reasons why people would perfer C++ to D are probably habit and convenience. If you've used C++ for years why should you bother to learn D? After all, C++ is well established, well-documented, has loads of libraries, will get you a job more eaily etc. Language features and performance are sometimes over-estimated when it comes to analyzing why a language succeeded. There's convenience, marketing (propaganda) etc etc.
>>
>> Also I don't think that performance alone decides whether a language becomes popular or not. If it were soley down to performance we wouldn't have Java or Python or even Objective-C (which used to be criticized for being too slow). Ease of use, a clear and consistent structure and "write once run everywhere" are very important too. Especially now that developers have to face so many different platforms (Linux, Mac, Windows, Android, iOS) everythnig goes into the direction of "write once ..." That's one of the reasons why Android took off, I think, because developers said "Great, maybe this will put an end to the mobile platform jungle. We'll support Android, less headaches for us!".
>
> I'm trying to analyze the problem from a strategic point of view. For this, I like to invoke the Serenity Prayer (please forgive any distasteful theology):
>
> "God, grant me the serenity to accept the things I cannot change,
> The courage to change the things I can,
> And wisdom to know the difference."
>
> So yeah, you can't control people's choices. The question is, of the things which *can* be done, is it better to focus on well-roundedness, or to press an advantage where one is already ahead of the pack? Which will lead to greater adoption of the language?
>
> One thing about performance in particular is that it's easy to measure and easy for the naive person to understand what it is. So there is perhaps a risk of being seduced into sacrificing other things which are more subtle, but equally important, in favor of winning at performance. Yet I think the key point is that that's not going to happen here. I personally have too much respect for the engineers working on this thing to think they would be that short-sighted.
>
> But if it's *possible* to grab a performance trophy while still keeping the other flocks well-fed, it seems like a clear strategic win.

Yes and no. I've actually given up pointing out language features or even performance to people. Believe it or not, but usually the first questions are things like "Does it have libraries? If it doesn't have a sound library I will not use it ..." And if someone is a die-hard D-hater s/he will always find something like "D doesn't support multi-sync-runtime-polymorphy on reversed backtracking array slicing, so it's useless! C# will have it soon!"

I think being an all-rounder is a good approach, you can use it for small script-like projects and big projects with unit tests, component programming etc. So as people ask about features, you just keep ticking the boxes. But if you start to point out one feature in particular, you're going down the slippery road of bit-by-bit language comparison, which will lead you nowhere.

I think it would help a lot if we had a "Made with D" list, especially if there are some killer apps or games and the like.

On Sun, 25 Aug 2013 17:06:27 +0200
"bearophile" <bearophileHUGS@lycos.com> wrote:

> Probably working even more you can make the D entry a bit more statically safe (eventually you could reach the level of Ada code) but the amount of work and code becomes excessive, and the resulting D code becomes unnatural, and rather not idiomatic.

Still considering whether to focus on Ada or D for my project, I wonder if D can do stuff like (from wikipedia page):

type Day_type   is range    1 ..   31;
type Month_type is range    1 ..   12;
type Year_type  is range 1800 .. 2100;
type Hours is mod 24;
type Weekday is (Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday);

type Date is
   record
     Day   : Day_type;
     Month : Month_type;
     Year  : Year_type;
   end record;

subtype Working_Hours is Hours range 0 .. 12;
subtype Working_Day is Weekday range Monday .. Friday;

Work_Load: constant array(Working_Day) of Working_Hours
   := (Friday => 6, Monday => 4, others => 10);


and ensure type-safety for such custom types?


Sincerely,
Gour

-- 
You have a right to perform your prescribed duty, but you
are not entitled to the fruits of action. Never consider
yourself the cause of the results of your activities,
and never be attached to not doing your duty.

http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810

On Thursday, 29 August 2013 at 13:33:52 UTC, Gour wrote:
> On Sun, 25 Aug 2013 17:06:27 +0200
> "bearophile" <bearophileHUGS@lycos.com> wrote:
>
>> Probably working even more you can make the D entry a bit more
>> statically safe (eventually you could reach the level of Ada code) but
>> the amount of work and code becomes excessive, and the resulting D
>> code becomes unnatural, and rather not idiomatic.
>
> Still considering whether to focus on Ada or D for my project, I wonder
> if D can do stuff like (from wikipedia page):
>
> type Day_type   is range    1 ..   31;
> type Month_type is range    1 ..   12;
> type Year_type  is range 1800 .. 2100;
> type Hours is mod 24;
> type Weekday is (Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday);
> 
> type Date is
>    record
>      Day   : Day_type;
>      Month : Month_type;
>      Year  : Year_type;
>    end record;
>
> subtype Working_Hours is Hours range 0 .. 12;
> subtype Working_Day is Weekday range Monday .. Friday;
> 
> Work_Load: constant array(Working_Day) of Working_Hours
>    := (Friday => 6, Monday => 4, others => 10);
>
>
> and ensure type-safety for such custom types?
>
>
> Sincerely,
> Gour

just something I whipped up in a few mins:
import std.typecons;
import std.exception;

struct Limited(T, T lower, T upper)
{
	T _t;
	mixin Proxy!_t; //Limited acts as T (almost)
	invariant()
	{
		enforce(_t >= lower && _t <= upper);
	}
	this(T t)
	{
		_t = t;
	}
}

auto limited(T, T lower, T upper)(T init = T.init)
{
	return Limited!(T, lower, upper)(init);
}

unittest
{
	enum l = [-4,9];
	auto a = limited!(int, l[0], l[1])();
	foreach(i; l[0] .. l[1]+1)
	{
		a = i;
	}
	
	assertThrown({a = -5;}());
	assertThrown({a = 10;}());
}


This could be a lot more generic than it is. Redesigning Restricted to hold a pointer to a function that does the check would be one way.

On Thursday, 29 August 2013 at 14:13:07 UTC, John Colvin wrote:
>
> This could be a lot more generic than it is. Redesigning Restricted to hold a pointer to a function that does the check would be one way.

Sorry, should read "Limited" not "Restricted" there

On 29/08/13 16:13, John Colvin wrote:
> struct Limited(T, T lower, T upper)
> {
>      T _t;
>      mixin Proxy!_t; //Limited acts as T (almost)
>      invariant()
>      {
>          enforce(_t >= lower && _t <= upper);
>      }
>      this(T t)
>      {
>          _t = t;
>      }
> }

Is the invariant() not going to be stripped out at compile time if you use -release ?

Joseph Rushton Wakeling:

> Is the invariant() not going to be stripped out at compile time if you use -release ?

Right. assert is enough there. Use enforce() only in special cases, when you need it. Better to minimize the usage of enforce() in library code that has to be called many times.

Bye,
bearophile

On Thursday, 29 August 2013 at 14:34:37 UTC, Joseph Rushton Wakeling wrote:
> On 29/08/13 16:13, John Colvin wrote:
>> struct Limited(T, T lower, T upper)
>> {
>>     T _t;
>>     mixin Proxy!_t; //Limited acts as T (almost)
>>     invariant()
>>     {
>>         enforce(_t >= lower && _t <= upper);
>>     }
>>     this(T t)
>>     {
>>         _t = t;
>>     }
>> }
>
> Is the invariant() not going to be stripped out at compile time if you use -release ?

sadly, yes. We need a release version of them, just like we have enforce and assert. Unfortunately in this case it won't be a library solution and will need compiler support.

On Thursday, 29 August 2013 at 14:37:10 UTC, bearophile wrote:
> Joseph Rushton Wakeling:
>
>> Is the invariant() not going to be stripped out at compile time if you use -release ?
>
> Right. assert is enough there. Use enforce() only in special cases, when you need it. Better to minimize the usage of enforce() in library code that has to be called many times.
>
> Bye,
> bearophile

fair point. I had forgotten that invariant would be stripped out anyway.

On Thu, 29 Aug 2013 16:13:06 +0200
"John Colvin" <john.loughran.colvin@gmail.com> wrote:

> just something I whipped up in a few mins:

[...]

Thanks. So, it's possible, but (maybe) it's not as elegant.


Sincerely,
Gour

-- 
A person is said to be established in self-realization and is called a yogī [or mystic] when he is fully satisfied by virtue of acquired knowledge and realization. Such a person is situated in transcendence and is self-controlled. He sees everything — whether it be pebbles, stones or gold — as the same.

http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810