December 12, 2011
On Sun, 11 Dec 2011 16:17:20 -0500, Timon Gehr <timon.gehr@gmx.ch> wrote:

> On 12/11/2011 10:12 PM, Timon Gehr wrote:
>> On 12/11/2011 06:49 PM, Paulo Pinto wrote:
>>> Am 11.12.2011 17:40, schrieb so:
>>>> On Sun, 11 Dec 2011 18:33:07 +0200, Paulo Pinto <pjmlp@progtools.org>
>>>> wrote:
>>>>
>>>>> Really?
>>>>>
>>>>> Tell that to all game studios developing games in Java/C#/Flash.
>>>>>
>>>>> Do you know that many games in iPhone are done in Unity, which
>>>>> makes use of C#/Boo/Javascript compiled to native code?
>>>>
>>>> I don't understand sorry, are you arguing against the argument i made on
>>>> GCs failure on some specific areas?
>>>
>>> Yes I am, since I know many areas where GC enabled languages have been
>>> replacing non-GC languages for better or worse.
>>>
>>> But then again, I am only a lurker here, so take my arguments with a
>>> grain of salt.
>>>
>>> As a non user of D, I cannot really say much.
>>
>> GC does not scale if an application has to be responsive. In all other
>> cases it is a valid choice.
>
> (if you have enough spare memory)

Don't confuse druntime's GC with the concept of a GC.  Better implemented GCs work quite well in practice, even for making responsive apps.

In general, however, GC's need more memory than manually managed code.  So for environments where memory is very limited, non-GC is pretty much the only option.

-Steve
December 12, 2011
On 12/12/2011 03:00 PM, Steven Schveighoffer wrote:
> On Sun, 11 Dec 2011 16:17:20 -0500, Timon Gehr <timon.gehr@gmx.ch> wrote:
>
>> On 12/11/2011 10:12 PM, Timon Gehr wrote:
>>> On 12/11/2011 06:49 PM, Paulo Pinto wrote:
>>>> Am 11.12.2011 17:40, schrieb so:
>>>>> On Sun, 11 Dec 2011 18:33:07 +0200, Paulo Pinto <pjmlp@progtools.org>
>>>>> wrote:
>>>>>
>>>>>> Really?
>>>>>>
>>>>>> Tell that to all game studios developing games in Java/C#/Flash.
>>>>>>
>>>>>> Do you know that many games in iPhone are done in Unity, which
>>>>>> makes use of C#/Boo/Javascript compiled to native code?
>>>>>
>>>>> I don't understand sorry, are you arguing against the argument i
>>>>> made on
>>>>> GCs failure on some specific areas?
>>>>
>>>> Yes I am, since I know many areas where GC enabled languages have been
>>>> replacing non-GC languages for better or worse.
>>>>
>>>> But then again, I am only a lurker here, so take my arguments with a
>>>> grain of salt.
>>>>
>>>> As a non user of D, I cannot really say much.
>>>
>>> GC does not scale if an application has to be responsive. In all other
>>> cases it is a valid choice.
>>
>> (if you have enough spare memory)
>
> Don't confuse druntime's GC with the concept of a GC. Better implemented
> GCs work quite well in practice, even for making responsive apps.
>

I certainly don't confuse them (GC wouldn't be very interesting if the two were the same), and as I understand it there exist very few GC implementations that _guarantee_ responsiveness over a long time period. This effect gets a lot bigger as memory usage and reference mutation rate grow. It is very easy for a sufficiently big Java application, for instance, to get responsiveness problems.
December 12, 2011
On Mon, 12 Dec 2011 10:00:28 -0500, Timon Gehr <timon.gehr@gmx.ch> wrote:

> On 12/12/2011 03:00 PM, Steven Schveighoffer wrote:
>> On Sun, 11 Dec 2011 16:17:20 -0500, Timon Gehr <timon.gehr@gmx.ch> wrote:
>>
>>> On 12/11/2011 10:12 PM, Timon Gehr wrote:
>>>> On 12/11/2011 06:49 PM, Paulo Pinto wrote:
>>>>> Am 11.12.2011 17:40, schrieb so:
>>>>>> On Sun, 11 Dec 2011 18:33:07 +0200, Paulo Pinto <pjmlp@progtools.org>
>>>>>> wrote:
>>>>>>
>>>>>>> Really?
>>>>>>>
>>>>>>> Tell that to all game studios developing games in Java/C#/Flash.
>>>>>>>
>>>>>>> Do you know that many games in iPhone are done in Unity, which
>>>>>>> makes use of C#/Boo/Javascript compiled to native code?
>>>>>>
>>>>>> I don't understand sorry, are you arguing against the argument i
>>>>>> made on
>>>>>> GCs failure on some specific areas?
>>>>>
>>>>> Yes I am, since I know many areas where GC enabled languages have been
>>>>> replacing non-GC languages for better or worse.
>>>>>
>>>>> But then again, I am only a lurker here, so take my arguments with a
>>>>> grain of salt.
>>>>>
>>>>> As a non user of D, I cannot really say much.
>>>>
>>>> GC does not scale if an application has to be responsive. In all other
>>>> cases it is a valid choice.
>>>
>>> (if you have enough spare memory)
>>
>> Don't confuse druntime's GC with the concept of a GC. Better implemented
>> GCs work quite well in practice, even for making responsive apps.
>>
>
> I certainly don't confuse them (GC wouldn't be very interesting if the two were the same), and as I understand it there exist very few GC implementations that _guarantee_ responsiveness over a long time period. This effect gets a lot bigger as memory usage and reference mutation rate grow. It is very easy for a sufficiently big Java application, for instance, to get responsiveness problems.

Oh, I've seen it first hand, I use netbeans.

But I'm not sure it's due to the GC, and not due to it requiring 2x or more memory than an equivalent manually managed application requires.  I honestly don't konw.

Generally bad things happen when memory gets low, no matter what the memory management system or language.

-Steve
December 12, 2011
On Saturday, 10 December 2011 at 19:23:02 UTC, Andrei Alexandrescu wrote:
> Sure, we can label Mehrdad as a whiny baby, but I suspect his experience is representative for the out-of-the-box experience of many others: they see D's cool features, they download the compiler to try it out on their own terms, and as soon as they deviate from what is tried and works, or they combine features in an unusual yet meaningful manner, it all comes unglued.

As a new member myself, I can testify to this.
After stumbling upon D (via TIOBE top 20) I was very excited to find an open-source language with a focus on productivity AND efficiency. I bought TDPL book and dove in. However, I sunk a bit when I realized some features listed in the book where either missing or broken.

My biggest disappointment was(/is) with the lack of the alleged Pseudo Methods (section 5.9.1). It's one thing to play around with a language you understand is growing and under development. It's another to boast about the language to your co-workers, only to receive unexpected errors when they ask for demonstrations :/
Bad for publicity, that.


With that said, I think 2.057 should be released soon, and major bug resolution should be a focus of 2.058. Beyond bugs and missing features, D's weakest area with many of my co-workers, and with myself, is it's platform support. The company I work for chose C#/WPF as foundations of a major product a few years ago and now we are paying for that choice with so much of the market focused on cross-platform, web, and mobile platforms. Mac OSX x86_64 support is very needed in D and I hope Window x86_64 and ARM support will be the major focus going forward.

D's ambitions far exceed other languages I've come across and I look forward to I'm sure is a bright future for the language.

-Philip


December 12, 2011
F i L:

> and I look forward to I'm sure is a bright future for the language.

http://www.youtube.com/watch?v=meRgT5Nmogw

Yeah yeah yeah,
bearophile
December 12, 2011
On Monday, 12 December 2011 at 13:56:22 UTC, Manu wrote:
> Yes, there are engines which implement *game logic* using GC based
> scripts/JIT-ers, but both the ENGINES you mention are still written in
> C/C++, and have very tight control of the hardware. Given this example, are
> you suggesting D is a scripting language to sit above some C/C++ app? For
> me, that's the opposite of what D is.

I've thought before how well suited D is for a Unity-style game engine. D's an obvious choice for the engine internals, but why not use it in replacement of game logic "scripts" as well? SafeD is just as easy to understand as C# or Unity's Javascript (relatively). Only you'd get the added benefit of native performance on game logic blocks, which could easily be packaged with the engine for release. For an editor, it should be easy enough to utilize DMD to compile game-logic files into their own temporary executable dynamically (or dynamic library?) which would pass messages to the engine running in-editor.
December 12, 2011
Am 12.12.2011 14:56, schrieb Manu:
> Yes, there are engines which implement /game logic/ using GC based
> scripts/JIT-ers, but both the ENGINES you mention are still written in
> C/C++, and have very tight control of the hardware. Given this example,
> are you suggesting D is a scripting language to sit above some C/C++
> app? For me, that's the opposite of what D is.

No, because those scripts as you call it, are compiled to native code
as well. I see no difference from C/C++ code.
December 12, 2011
On Monday, December 12, 2011 19:48:11 F i L wrote:
> My biggest disappointment was(/is) with the lack of the alleged Pseudo Methods (section 5.9.1). It's one thing to play around with a language you understand is growing and under development. It's another to boast about the language to your co-workers, only to receive unexpected errors when they ask for demonstrations :/ Bad for publicity, that.

I think that that section was not clear enough. Calling free functions as if they were member functions on a type works with arrays and has only ever worked with arrays. TDPL doesn't actually say that it works with anything other than arrays. It talks about adding them to built-in types and specifically talks about arrays, but it's not particularly clear about anything other than arrays. My guess is that it was never intended to mean anything other than arrays, but I don't know. Only Andrei would know that.

There has been discussion of UFCS (universal function call syntax), which would then expand that beyond arrays to _all_ types - int, float, any user- defined type, etc. However, there are a number of issues with that (particularly with user-defined types; e.g. what if a member function and a free function have the same name?), and it has yet to be implemented. It may never be implemented.

So, I think that there's a decent chance that you just misunderstood what that section in TDPL was really saying (it really should be clearer on whether it meant just arrays or all types), but there are definitely folks who want it to be extended to all types, so it may be eventually, but we'll have to wait and see.

- Jonathan M Davis
December 13, 2011
On Monday, 12 December 2011 at 21:57:36 UTC, Jonathan M Davis wrote:
> There has been discussion of UFCS (universal function call syntax), which would then expand that beyond arrays to _all_ types - int, float, any user-
> defined type, etc. However, there are a number of issues with that (particularly with user-defined types; e.g. what if a member function and a free function have the same name?), and it has yet to be implemented. It may never be implemented.

C# easily avoids member confusion with pseudo methods by using the 'this' keyword as a parameter attribute in the pseudo method (http://msdn.microsoft.com/en-us/library/bb383977.aspx). Any function(this a, b) can be invoked as: a.function(b) in C#. I understand using the 'this' keyword as a parameter attribute already serves a different purpose in D, but I'm sure another keyword ('pseudo' perhaps?) or equivalent syntax could be reached. At which point, any external pseudo method conflicting with an objects internal members could simply result in a compiler error (or, member functions could take priority over pseudo methods).

I understand this isn't exactly a priority, but IMO it could really help the overall syntax feel more consistent in some areas.

   import std.conv;

   void main()
   {
       string encoded = "1324.03";
       double actual = encoded.to!string; // similar to Object.toString()
   }

More importantly, pseudo methods could be used to bend the rules of member access, and to implement module-specific functionality for imported objects without breaking OOP syntax.

   module a;

   class A {
       int data;
   }

   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

   module b;

   pseudo void foo(A a, B b) {
       // A can access B's private members
       a.data = b._data;
   }

   class B {
       private int _data;
   }

   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

   import a, b;

   void main() {
       auto a = new A();
       auto b = new B();

       a.foo(b); // cool!
   }


> So, I think that there's a decent chance that you just misunderstood what that section in TDPL was really saying (it really should be clearer on whether it meant just arrays or all types), but there are definitely folks who want it to be extended to all types, so it may be eventually, but we'll have to wait and see.

Undoubtedly a misunderstanding on my end. Still, +1 for seeing Pseudo Members for all types.

- Philip


December 13, 2011
On Tuesday, December 13, 2011 05:13:29 F i L wrote:
> On Monday, 12 December 2011 at 21:57:36 UTC, Jonathan M Davis
> 
> wrote:
> > There has been discussion of UFCS (universal function call
> > syntax), which would then expand that beyond arrays to _all_
> > types - int, float, any user-
> > defined type, etc. However, there are a number of issues with
> > that (particularly with user-defined types; e.g. what if a
> > member function and a free function have the same name?), and
> > it has yet to be implemented. It may never be implemented.
> 
> C# easily avoids member confusion with pseudo methods by using the 'this' keyword as a parameter attribute in the pseudo method (http://msdn.microsoft.com/en-us/library/bb383977.aspx). Any function(this a, b) can be invoked as: a.function(b) in C#. I understand using the 'this' keyword as a parameter attribute already serves a different purpose in D, but I'm sure another keyword ('pseudo' perhaps?) or equivalent syntax could be reached. At which point, any external pseudo method conflicting with an objects internal members could simply result in a compiler error (or, member functions could take priority over pseudo methods).

There have been a variety of suggestions on how to do it - including one similar to what you're suggesting with the this keyword. However, it still leaves the problem of disambiguation that I mentioned. What happens when there's a free function and a member function with the same name and same parameters? Which one gets called? It's issues like that which are more of a problem than the exact syntax for declaring it IMHO. And all of those details need to be sorted out in a satisfactory manner before we can add UFCS to the language in any form.

For arrays, all you need to do is have the first argument be an array, and that works great for arrays, but arrays don't have much in the way of functions built in, so there's no conflict.

Realistically, at this point, I'd expect that if UFCS gets added any time soon, it's going to require that someone other than Walter do it and that they have do it very solidly, otherwise it could be a long time before it stands any chance of happening, simply because Walter is focused on fixing major bugs and stabilizing the compiler and isn't likely to look at adding new features anytime soon if there's no dire need (even if they're backwards compatible).

- Jonathan M Davis