On Friday, 29 November 2013 at 08:35:58 UTC, Bienlein wrote:
> Could you just quickly describe what you mean by "being forced to move
> lot of things to run-time"? I simply don't see what you are refering to.

For example the dreaded generics issue. You can workaround it in many cases by using common polymorphic storage types but it costs. Or some applications of declarative programming in D - one can avoid using reflection and just move base data to runtime values but that requires to do processing during runtime.

In your Rectangular example the difference will start to appear when one wants to express a function that accepts any Rectangular type. As far as I know, in Go only option uses fat pointer. In D you can also express it as template constrain and thus can make more finely tuned design decision.

On 2013-11-29 16:15, Dicebot wrote:

> After that just make symlink to dmd binary and add Phobos/druntime paths
> to dmd.conf and you are ready to go.

dmd.conf.default is only for Linux. There's also no sc.ini for Windows.

-- 
/Jacob Carlborg

On Friday, 29 November 2013 at 15:34:21 UTC, Jacob Carlborg wrote:
> On 2013-11-29 16:15, Dicebot wrote:
>
>> After that just make symlink to dmd binary and add Phobos/druntime paths
>> to dmd.conf and you are ready to go.
>
> dmd.conf.default is only for Linux. There's also no sc.ini for Windows.

Pardon my ignorance, I have never used D on Windows. Well, I guess at least building part should be pretty much the same (afair make binary for Windows is in distribution)

On Friday, 29 November 2013 at 15:21:26 UTC, Chris Cain wrote:
> On Friday, 29 November 2013 at 12:06:17 UTC, Chris wrote:
>> [1] Raises the question whether we've been conditioned by C or whether C was intuitive.
>
> I'll answer for you: C was very counter intuitive which is why no one has done exactly what it did since. Look up the spiral rule for reading types in C. Most often it can be thought of being read from right to left, but that's not the actual reading.
>
> http://c-faq.com/decl/spiral.anderson.html
>
> D fixes this massive issue to a certain degree, but it still feels backwards to me, despite me having been raised with "types on the left of the name". After using a language doing it "the right way" for awhile, you quickly adapt and realize it makes the most sense.
>
> At least, that's the way that I feel.

I agree that D, too, can be a bit confusing. I sometimes have problems with AA declarations.

Example:

string[string][string] hm; // What am I?

But I don't think it's the reading direction. I wonder why you would want the variable name first.

var omitNewline bool

or

func (r RepeatByte) Read(p []byte) (n int, err error)

or ":="

or "var". _Of course_ it's a variable:

bool yes;
string answer;

For my liking Go code looks too cluttered (pointing out the obvious). But I guess it's just the way you're "brought up" with a language. Maybe I'm a dinosaur.

On 11/29/2013 12:29 AM, Bienlein wrote:
> I guess in D you would do something like this:
>
> mixin template Rectangular() {
>    Point x, y;
> }
>
> mixin Rectangular;
>
> struct Rectangle {
>    mixin Rectangular;
> }

It's easier than that:

struct Rectangular {
    Point x,y;
}

struct Rectangular {
    Rectangle rectangle;
    alias this rectangle;
}

On Saturday, 30 November 2013 at 18:16:23 UTC, Walter Bright wrote:
> On 11/29/2013 12:29 AM, Bienlein wrote:
>> I guess in D you would do something like this:
>>
>> mixin template Rectangular() {
>>   Point x, y;
>> }
>>
>> mixin Rectangular;
>>
>> struct Rectangle {
>>   mixin Rectangular;
>> }
>
> It's easier than that:
>
> struct Rectangular {
>     Point x,y;
> }
>
> struct Rectangular {
>     Rectangle rectangle;
>     alias this rectangle;
> }

D is always full of surprises ;-). Now the only feature in Go that sets it apart from other languages is CSP.

I got this to work with help from the book by Ali Çehreli:

struct Point {
    int x,y;
}

struct Rectangular {
    Point x,y;
}

struct Rectangle  {
    Rectangular rectangular;
	
    Rectangular rect() const {
	return rectangular;
    }
	
    alias rect this;
}

void main(string[] args)
{
	Rectangle rectangle = Rectangle();
	rectangle.x = Point();
}

On Friday, 22 November 2013 at 23:08:38 UTC, Andrei Alexandrescu wrote:
> On 11/22/13 1:49 PM, Max Samukha wrote:
>> On Wednesday, 6 November 2013 at 19:42:21 UTC, Andrei Alexandrescu wrote:
>>
>>> Go's team was unable to add generics to the language.
>>
>> Not adding generics was Go's deliberate decision.
>
> http://golang.org/doc/faq#generics
>
> "We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it."

Ok, I stand corrected.

>
>> For that matter, D got
>> its type system all wrong compared to Haskell. So why won't we all move
>> there?
>
> Move where?
>

Tried to implement a GADT in D?

>
> Andrei

On Friday, 29 November 2013 at 16:15:10 UTC, Chris wrote:
> I agree that D, too, can be a bit confusing. I sometimes have problems with AA declarations.
>
> Example:
>
> string[string][string] hm; // What am I?
>
> But I don't think it's the reading direction.

Actually it is. D is pretty good about being consistently read backwards (which, as you can tell, is a tiny bit awkward, hence why I think "the other way" is better).

hm is an associative array mapping string to another associative array mapping string to string.

Pseudocode:
hm [string][string]string;


How about something *ridiculous* in right-to-left reading:

rofl *[string][]*bool;

Try to read that before seeing what's below:

-----

rofl is a pointer to an associative array mapping strings to arrays of pointers to bools. Very simple and very intuitive. After reading a few things like that you become very comfortable with it.

> I wonder why you would want the variable name first.

It's really irrelevant either way, but it "reads out loud" much better in my experience

> For my liking Go code looks too cluttered (pointing out the obvious). But I guess it's just the way you're "brought up" with a language. Maybe I'm a dinosaur.

I'm not suggesting Go got it perfectly. I've seen a lot of languages that have cleaner declarations, IMO. To be honest, Go looks kind of cluttered in my eyes too. But the right-to-left reading order is something I'm a very strong proponent of. I'm fine with D, however, since you can usually reliably read it backwards. C, however, is a horrific mess.

On 11/30/2013 12:36 PM, Bienlein wrote:
> D is always full of surprises ;-).

The syntax for alias this is a bit off-putting to me, but it works great.

On Saturday, 30 November 2013 at 21:14:53 UTC, Max Samukha wrote:
> On Friday, 22 November 2013 at 23:08:38 UTC, Andrei Alexandrescu wrote:
>> On 11/22/13 1:49 PM, Max Samukha wrote:
>>> On Wednesday, 6 November 2013 at 19:42:21 UTC, Andrei Alexandrescu wrote:
>>>
>>>> Go's team was unable to add generics to the language.
>>>
>>> Not adding generics was Go's deliberate decision.
>>
>> http://golang.org/doc/faq#generics
>>
>> "We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it."
>
> Ok, I stand corrected.
>
>>
>>> For that matter, D got
>>> its type system all wrong compared to Haskell. So why won't we all move
>>> there?
>>
>> Move where?
>>
>
> Tried to implement a GADT in D?

To clarify:

"Go's built-in maps and slices, plus the ability to use the empty interface to construct containers (with explicit unboxing) mean in many cases it is possible to write code that does what generics would enable, if less smoothly."

Can you implement a GADT in D as "smoothly" as in Haskell?