View mode: basic / threaded / horizontal-split · Log in · Help
December 12, 2011
Re: If I had my way
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
Re: If I had my way
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
Re: If I had my way
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
Re: If I had my way
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
Re: If I had my way
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
Re: If I had my way
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
Re: If I had my way
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
Re: If I had my way
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
Re: If I had my way
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
Re: If I had my way
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
4 5 6 7 8 9 10 11 12
Top | Discussion index | About this forum | D home