January 09, 2012
On Sunday, 8 January 2012 at 23:28:57 UTC, Mehrdad wrote:
> On 1/7/2012 10:57 PM, Jonathan M Davis wrote:
>> Not exactly the most informed discussion.
>
> Well, some of their comments _ARE_ spot-on correct...

computerquip did a very good job highlighting the bad points. rapidcoder failed miserably to provide accurate claims. Most of the discussion is these two going back and forth (where computerquip states rapidcoder's inability to argue).

The conclusion that not a systems language is the only thing I partially disagree with from computerquip. I don't think it can be used for such at this time, or at least not it a way that is any better than C (and may even be worse in some situations). But systems programming is a goal, we just don't have a big enough section in the community spending time to improve this area.

Sadly there isn't anything new that we can take away from this discussion.
January 09, 2012
On Sun, 08 Jan 2012 19:26:15 -0500
dsimcha <dsimcha@yahoo.com> wrote:

> As someone who does performance-critical scientific work in D, this comment is absolutely **wrong** because you only need to avoid the GC in the most performance-critical/realtime parts of your code, i.e. where you should be avoiding any dynamic allocation, GC or not.

Considering we'd need to do some work for our project involving number crunching in the form of producing several libs to be (later) used by GUI part of the app, I'm curious to know do you use ncurses or just plain console output for your UI?

I'm askin considering to start work on non-GUI part of the project and just have simple UI to test results and along with that work try to improve GUI situation in the D's ecosystem.

> Bottom line:  D doesn't give you a free lunch but it does give you a cheaper lunch than C, C++ or even a combination of C/C++ and Python.

That's vey nice to hear from someone like yourself. We did small research about possible alternatives for D by looking at Scala & Clojure, but understood we don't get much in terms of GUIs, but only lose otherwise.

Last consideration was C#/Mono, but, again, not much to gain and more to lose, so we'll stay with D, try to write non-GUI parts and later (hopefully) sell D as overall language of the projet.


Sincerely,
Gour

-- 
Never was there a time when I did not exist, nor you, nor all these kings; nor in the future shall any of us cease to be.

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


January 09, 2012
On 1/8/2012 7:09 PM, Vladimir Panteleev wrote:
> On Sunday, 8 January 2012 at 23:28:57 UTC, Mehrdad wrote:
>> 7. Unstable language. They're currently considering doing things like removing "delete" as it's apparently deprecated (which will officially make it not usable as an SP language).
>>   Looks 100% correct. Removing 'delete' /does/ make D unusable as an SP language... unless you ignore the GC completely, which isn't even possible, practically speaking.
>
> I don't understand how you came to that conclusion? "delete" will become a standard library (or easily-implemented user) function.
Would it still have the same functionality (i.e. disposing of GC'd objects and reclaiming their memory, as though the GC had done it)?
If so, what's the point of removing it in the first place?
If not, then I guess my point is obvious.
January 09, 2012
On Monday, January 09, 2012 00:51:57 Mehrdad wrote:
> On 1/8/2012 7:09 PM, Vladimir Panteleev wrote:
> > On Sunday, 8 January 2012 at 23:28:57 UTC, Mehrdad wrote:
> >> 7. Unstable language. They're currently considering doing things like removing "delete" as it's apparently deprecated (which will officially make it not usable as an SP language).
> >> 
> >>   Looks 100% correct. Removing 'delete' /does/ make D unusable as an
> >> 
> >> SP language... unless you ignore the GC completely, which isn't even possible, practically speaking.
> > 
> > I don't understand how you came to that conclusion? "delete" will become a standard library (or easily-implemented user) function.
> 
> Would it still have the same functionality (i.e. disposing of GC'd
> objects and reclaiming their memory, as though the GC had done it)?
> If so, what's the point of removing it in the first place?
> If not, then I guess my point is obvious.

I believe that the general idea is that if you want to manually manage memory, then you don't use the GC heap, though core.memory.GC will still allow some level of manual control for the GC. I'm not aware of any plan to add a "delete" function to anything, but if something like that is added, it'll probably be to core.memory with the idea that it's there if you really need it but that you really shouldn't be using it normally. Explicitly freeing memory goes with manually memory management, not garbage collection.

- Jonathan M Davis
January 09, 2012
Jonathan M Davis wrote:

> On Monday, January 09, 2012 00:51:57 Mehrdad wrote:
>> On 1/8/2012 7:09 PM, Vladimir Panteleev wrote:
>> > On Sunday, 8 January 2012 at 23:28:57 UTC, Mehrdad wrote:
>> >> 7. Unstable language. They're currently considering doing things like removing "delete" as it's apparently deprecated (which will officially make it not usable as an SP language).
>> >> 
>> >>   Looks 100% correct. Removing 'delete' /does/ make D unusable as an
>> >> 
>> >> SP language... unless you ignore the GC completely, which isn't even possible, practically speaking.
>> > 
>> > I don't understand how you came to that conclusion? "delete" will become a standard library (or easily-implemented user) function.
>> 
>> Would it still have the same functionality (i.e. disposing of GC'd
>> objects and reclaiming their memory, as though the GC had done it)?
>> If so, what's the point of removing it in the first place?
>> If not, then I guess my point is obvious.
> 
> I believe that the general idea is that if you want to manually manage memory, then you don't use the GC heap, though core.memory.GC will still allow some level of manual control for the GC. I'm not aware of any plan to add a "delete" function to anything, but if something like that is added, it'll probably be to core.memory with the idea that it's there if you really need it but that you really shouldn't be using it normally. Explicitly freeing memory goes with manually memory management, not garbage collection.
> 
> - Jonathan M Davis

AFAIK, core.memory.GC.free() can be used to manually deallocate GC allocated data (you'll have to clear the classes to destroy them, though).

But, correct, if you want manual allocation, you should use manual allocation. My game project uses GC all over the code - yet most memory is manually allocated as the largest allocations are in specific parts of code (mostly video related, e.g. textures). This way you get the benefits of both a GC and manual allocation.
January 09, 2012
On Sun, 08 Jan 2012 18:28:54 -0500, Mehrdad <wfunction@hotmail.com> wrote:

> 7. Unstable language. They're currently considering doing things like removing "delete" as it's apparently deprecated (which will officially make it not usable as an SP language).
>     Looks 100% correct. Removing 'delete' /does/ make D unusable as an SP language... unless you ignore the GC completely, which isn't even possible, practically speaking.

C doesn't have delete.

But removing delete isn't the problem anyways.  Here is the problem (which exists with delete present in the language):

class C
{
   private int[] buf;
   this() { buf = new int[5]; }
   ~this() {/* can't destroy buf here */}
}

void main()
{
   auto c = new C;
   delete c; // doesn't destroy c.buf
}

What we need is a way to hook deterministic destruction vs. GC destruction.  Only then, a SP language will you be.

-Steve
January 09, 2012
On 1/9/2012 2:56 AM, Gour wrote:
> On Sun, 08 Jan 2012 19:26:15 -0500
> dsimcha<dsimcha@yahoo.com>  wrote:
>
>> As someone who does performance-critical scientific work in D, this
>> comment is absolutely **wrong** because you only need to avoid the GC
>> in the most performance-critical/realtime parts of your code, i.e.
>> where you should be avoiding any dynamic allocation, GC or not.
>
> Considering we'd need to do some work for our project involving number
> crunching in the form of producing several libs to be (later) used by
> GUI part of the app, I'm curious to know do you use ncurses or just
> plain console output for your UI?

Pure command line/console.

January 09, 2012
On Mon, 09 Jan 2012 09:28:11 -0500
dsimcha <dsimcha@yahoo.com> wrote:

> Pure command line/console.

Thank you.


Sincerely,
Gour

-- 
As a strong wind sweeps away a boat on the water, even one of the roaming senses on which the mind focuses can carry away a man's intelligence.

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


January 09, 2012
On Sunday, 8 January 2012 at 04:19:52 UTC, Andrei Alexandrescu wrote:
> Here's an interesting discussion that may reflect the perceptions and misperceptions about D within the larger community.

They did not touch any new topic we did not talk about here on this NG, and on irc://irc.freenode.org/d . :)

January 09, 2012
On 01/09/2012 07:58 AM, Steven Schveighoffer wrote:
> On Sun, 08 Jan 2012 18:28:54 -0500, Mehrdad <wfunction@hotmail.com> wrote:
>
>> 7. Unstable language. They're currently considering doing things like
>> removing "delete" as it's apparently deprecated (which will officially
>> make it not usable as an SP language).
>> Looks 100% correct. Removing 'delete' /does/ make D unusable as an SP
>> language... unless you ignore the GC completely, which isn't even
>> possible, practically speaking.
>
> C doesn't have delete.
>
> But removing delete isn't the problem anyways. Here is the problem
> (which exists with delete present in the language):
>
> class C
> {
> private int[] buf;
> this() { buf = new int[5]; }
> ~this() {/* can't destroy buf here */}
> }
>
> void main()
> {
> auto c = new C;
> delete c; // doesn't destroy c.buf
> }
>
> What we need is a way to hook deterministic destruction vs. GC
> destruction. Only then, a SP language will you be.
>
> -Steve

I was under the impression you could overload new and delete per class/union/struct which gave you the ability to control how things were allocated.

I was also under the impression that this would be longer possible with some of the comments made on IRC. I'm probably wrong (or I hope I'm wrong...).