On 08/04/2010 07:25 PM, Jeff Nowakowski wrote:
> On 08/04/2010 05:16 PM, Robert Clipsham wrote:
>>
>> I know of several large apps written in D, they're all D1/Tango.
>
> The incomplete state of D2 has to be the most embarrassing question that
> could have been asked at Andrei's talk, but then you'd have to be
> familiar with D to ask that question. Andrei likes to talk about
> presentations showing only what's good, but he gave a whole talk about
> an incomplete language while hawking his book for said language, but
> made no mention of D1 vs D2.
>
> People often ask for a status, but there never seems to be good answers.
> Where's the roadmap? What's being worked on? What's left to fix? Is
> there a release date that's being worked towards? It used to coincide
> with the release of Andrei's book, but that has come and gone.

Walter is more silent than usual because he's working very hard on the 64-bit compiler. He hopes to have one by the end of this month. His next big goal is shared library support.

Andrei

Andrei Alexandrescu:
> Walter is more silent than usual because he's working very hard on the 64-bit compiler. He hopes to have one by the end of this month. His next big goal is shared library support.

I am sorry to say this, but I think porting the current back-end to 64 bit is a waste of time because it will not be used for professional usages. I think LLVM will be the main back-end for professional usages of D2, with maybe GDC2 or later even a dotnet D2 compiler too.

I think it's more important for Walter to focus on filling D2 design holes, removing front-end bugs and implementing unfinished features (I'd also like Walter to modify the D2 front-end to make it a bit simpler to attach it to LLVM).

Bye,
bearophile

On 8/4/10, bearophile <bearophileHUGS@lycos.com> wrote:
> I am sorry to say this, but I think porting the current back-end to 64 bit is a waste of time because it will not be used for professional usages. I think LLVM will be the main back-end for professional usages of D2

Get back to me when LDC starts to actually /work/. It is *completely unusable* in its current state and its developers don't seem to care.

I don't understand what you see in it.

Adam Ruppe:
> Get back to me when LDC starts to actually /work/. It is *completely unusable* in its current state and its developers don't seem to care.

Go back to read my post again, it doesn't contain the name "LDC".

Bye,
bearophile

> Go back to read my post again, it doesn't contain the name "LDC".

But LDC is the D frontend for LLVM right, so wouldn't it be more useful to talk about LDC rather than LLVM?

== Quote from bearophile (bearophileHUGS@lycos.com)'s article
> Andrei Alexandrescu:
> > Walter is more silent than usual because he's working very hard on the 64-bit compiler. He hopes to have one by the end of this month. His next big goal is shared library support.
> I am sorry to say this, but I think porting the current back-end to 64 bit is a
waste of time because it will not be used for professional usages. I think LLVM will be the main back-end for professional usages of D2, with maybe GDC2 or later even a dotnet D2 compiler too.

Why is DMD not usable professionally?  I think that, since a key niche for D is scientific computing, 64-bit is an absolute must-have.  No other issue with D has caused me half as much pain as lack of 64-bit support when I use D for bioinformatics work on large datasets.  Not lack of shared library support, not misc. compiler bugs, not lack of library support, not lack of IDE support, not even lack of precise GC.  In hindsight, D is such an awesome language that I still don't regret using it and working around the lack of 64 support, but at times I felt like I was trapped in the caveman era with an old 8086 and the 640K barrier.

Yes, LDC will hopefully be ported to D2 eventually, or another LLVM-based D compiler might be written.  Yes, GDC2 may be caught up eventually.  Regardless, the flagship implementation still needs to be good at what the language claims to be good at, and if the language seems to be targetting scientific computing, and claims to be somewhat mature, lack of 64-bit support in the reference implementation is simply inexcusable.

P.S.  None of this should be construed as an attack, complaint, etc. against Walter.  I understand the need to get the core language spec stable before working on tool chain issues, and until recently D2 made no claim to being "somewhat mature".  Now that it is making that claim, 64-bit support is being taken seriously, as it should be.

Hello bearophile,

> Andrei Alexandrescu:
> 
>> Walter is more silent than usual because he's working very hard on
>> the 64-bit compiler. He hopes to have one by the end of this month.
>> His next big goal is shared library support.
>> 
> I am sorry to say this, but I think porting the current back-end to 64
> bit is a waste of time because it will not be used for professional
> usages. I think LLVM will be the main back-end for professional usages
> of D2, with maybe GDC2 or later even a dotnet D2 compiler too.
> 
> I think it's more important for Walter to focus on filling D2 design
> holes, removing front-end bugs and implementing unfinished features
> (I'd also like Walter to modify the D2 front-end to make it a bit
> simpler to attach it to LLVM).

For a number of IP/legal reasons, Walter CAN'T work on LLVM or LDC. So he needs to have a back end that he can work on so he's going to work on the back end he has, the one that DMD is using now. Also, I'll bet that about the same time that DMD64 comes out, DMC64 will to and that is also valuable in it's own right.

-- 
... <IXOYE><

On 03/08/10 22:56, Walter Bright wrote:
> bearophile wrote:
>> 27.50, "transactional file copy": this example was script-like, and as
>> short
>> as possible to fit into one single slide, so in this case I think using
>> enforce() is OK. But in true programs I suggest all D programmers to use
>> DesignByContract with assert() more and to use enforce() less. Among
>> other
>> things enforce() kills inlining possibilities and inflates code. In
>> D.learn I
>> have seen people use enforce() in a situation where DbC is designed
>> for. I
>> think the D community needs to learn a bit more DbC, and in my opinion
>> to do
>> this the leaders have to lead the way.
>
> There's a misunderstanding here. Contract programming is for detecting
> program bugs. enforce() is for detecting and handling errors such as
> disk failures and bad user input.
>
> They are COMPLETELY DIFFERENT and must not be conflated.
>
> (For example, assert() goes away when compiled with the -release switch.
> enforce() does not.)

I agree. Still, I agree with bearophile that 'enforce' should be avoided. It is a quick-and-dirty solution for situations where a proper exception should be issued. Essentially, an 'enforce' violation says "Something went wrong!" without giving a clue about the real problem. That's OK in the development phase but should be replaced when the code matures.

And as for the concept of "user input" vs. "contracts": A library interface is *not* a user interface. After some consideration, I agree that a library should always check its input even in "release" mode. However - this should be solved by selectively toggling contract checking rather than replacing contracts by "enforce" statements.

On 2010-08-05 03:22, Andrei Alexandrescu wrote:
> On 08/04/2010 07:25 PM, Jeff Nowakowski wrote:
>> On 08/04/2010 05:16 PM, Robert Clipsham wrote:
>>>
>>> I know of several large apps written in D, they're all D1/Tango.
>>
>> The incomplete state of D2 has to be the most embarrassing question that
>> could have been asked at Andrei's talk, but then you'd have to be
>> familiar with D to ask that question. Andrei likes to talk about
>> presentations showing only what's good, but he gave a whole talk about
>> an incomplete language while hawking his book for said language, but
>> made no mention of D1 vs D2.
>>
>> People often ask for a status, but there never seems to be good answers.
>> Where's the roadmap? What's being worked on? What's left to fix? Is
>> there a release date that's being worked towards? It used to coincide
>> with the release of Andrei's book, but that has come and gone.
>
> Walter is more silent than usual because he's working very hard on the
> 64-bit compiler. He hopes to have one by the end of this month. His next
> big goal is shared library support.
>
> Andrei

For shared library support on Linux I think http://d.puremagic.com/issues/show_bug.cgi?id=4583 is a blocker. For Mac OS X a patch is already available (of which the dmd part has already been applied) http://d.puremagic.com/issues/show_bug.cgi?id=4080 . BTW compiling Tango as a dynamic library on Mac OS X has been possible the last couple of months.

-- 
/Jacob Carlborg

Hello Norbert,

> And as for the concept of "user input" vs. "contracts": A library
> interface is *not* a user interface. After some consideration, I agree
> that a library should always check its input even in "release" mode.
> However - this should be solved by selectively toggling contract
> checking rather than replacing contracts by "enforce" statements.

In some cases, particularly where the preconditions are external to the process, your assertion is severely weakened if it doesn't fail completely.

1) Checking external state is generally costly so why require it to be done twice?
2) It's error prone: because it's external state, in almost all cases the calling code will needs to implement the same check and treat it as an input error.
3) It sill doesn't work because external state, in general, can change between the check and the call.

A possibly better solution would be to use an error handling strategy approach, Have the called function throw and exception supplied by the calling function.

> 
-- 
... <IXOYE><