"Walter" <newshound@digitalmars.com> wrote in message news:da5l1t$9da$1@digitaldaemon.com...
>
> "Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:da5grk$3ff$1@digitaldaemon.com...
>>
>> "Walter" <newshound@digitalmars.com> wrote in message news:da56f7$2sbk$1@digitaldaemon.com...
>> >
>> > "Anders F Björklund" <afb@algonet.se> wrote in message news:da476t$2132$1@digitaldaemon.com...
>> >> Too bad that all that talking hasn't gotten us much further :-)
>> >> (still not sure it that's a "good one" or a "bad one" I got ?)
>> >
>> > I think the language has moved pretty far, according to the changelog.
>> >
>> >> I had planned on switching a big project from C and to D, but it looks like I have to choose another language instead I'm afraid.
>> >
>>
>>
>> > Why?
>> >
>>
>> I lost three projects which were seriosly considered for D initially.
>> In our case there was two reasons:
>> a) no const or equivalent (e.g. opAssign) ( three votes against one ) -
>> major reason for 12 developers team and estimated
>> 700000 lines of code in final products. Final decision - C++.
>
> I'm surprised they'd trade const for all the other safety features, such
> as
> array overflow checking, guaranteed initialization, DbC, etc.

All these and couple of things more was the main reason why we decided to consider D as a primary development language. (Harmonia was a proof of concept actually)

const and const references is a part of DbC and big one.
( http://en.wikipedia.org/wiki/Design_by_contract and from
there go to
http://en.wikipedia.org/wiki/Const_correctness )

opAssign/ctor/dtor for C++ programmer is also huge these days.

To be short: D has nice features but to convince somebody
to switch to it e.g. from C++, D shall demonstrate
that it:
1) can handle most popular design patterns.
2) has more features - simplifies development a lot.

Currently D 'has more ...' part (and attractive enough) but has
no basic C++ features (mentioned above) - and the worst thing
that you even cannot emulate them in D in principle (physically).

The same applied to Java and C# versus D.

E.g. you cannot implement std::string C++ class in D.
Yes, you can do something close but you will not be able to use slices with
it.
This is making one of most attractible features worthless.

There was multiple attempts to make string class in D but
all of them (without immutables and immutable slicing)
look unreliable for commercial software design.

>
>> b) no mobile platform support (one not so big project but with strong
> mobile
>> demand in perspective) - C++
>
> I'm not sure what this means.
>

There is no compiler proven to produce code for XScale
processors Windows CE (Mobile).

"Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:da7n5u$fqr$1@digitaldaemon.com...
>
> "Walter" <newshound@digitalmars.com> wrote in message news:da5l1t$9da$1@digitaldaemon.com...
> > I'm surprised they'd trade const for all the other safety features, such
> > as
> > array overflow checking, guaranteed initialization, DbC, etc.
>
> All these and couple of things more was the main reason why we decided to consider D as a primary development language. (Harmonia was a proof of concept actually)
>
> const and const references is a part of DbC and big one.
> ( http://en.wikipedia.org/wiki/Design_by_contract and from
> there go to
> http://en.wikipedia.org/wiki/Const_correctness )
> opAssign/ctor/dtor for C++ programmer is also huge these days.

The main use for opAssign I've seen (and if one does opAssign, one must do ctor's, dtor's) is to implement reference counting, or some other mechanism for managing memory. What other huge uses are there for it?


> To be short: D has nice features but to convince somebody
> to switch to it e.g. from C++, D shall demonstrate
> that it:
> 1) can handle most popular design patterns.
> 2) has more features - simplifies development a lot.
>
> Currently D 'has more ...' part (and attractive enough) but has
> no basic C++ features (mentioned above) - and the worst thing
> that you even cannot emulate them in D in principle (physically).
>
> The same applied to Java and C# versus D.

Java doesn't have const, nor does it have opAssign, nor scoped destruction, nor even structs. What's stopping you from making a Java.lang.String class in D?


> E.g. you cannot implement std::string C++ class in D.
> Yes, you can do something close but you will not be able to use slices
with
> it.
> This is making one of most attractible features worthless.
>
> There was multiple attempts to make string class in D but
> all of them (without immutables and immutable slicing)
> look unreliable for commercial software design.

Can I ask exactly what feature is motivating a desire for a string class? Is it the desire to make immutable strings?

> >> b) no mobile platform support (one not so big project but with strong
> > mobile
> >> demand in perspective) - C++
> >
> > I'm not sure what this means.
>
> There is no compiler proven to produce code for XScale
> processors Windows CE (Mobile).

Is there a gcc for it? If so, then one can make a gdc for it, though I admit that would probably not be an attractive idea for a team interested in building an app rather than a compiler.

Andrew Fedoniouk wrote:

>>>a) no const or equivalent (e.g. opAssign) ( three votes against one ) -
>>>major reason for 12 developers team and estimated
>>>700000 lines of code in final products. Final decision - C++.
>>
>>I'm surprised they'd trade const for all the other safety features, such as
>>array overflow checking, guaranteed initialization, DbC, etc.

hi,

I may be missing the obvious, but isn't there a lot
of constness that you can achieve with mode in parameters?


georg

"Georg Bauhaus" <bauhaus@futureapps.de> wrote in message news:da8di3$um2$1@digitaldaemon.com...
> Andrew Fedoniouk wrote:
>
>>>>a) no const or equivalent (e.g. opAssign) ( three votes against one ) -
>>>>major reason for 12 developers team and estimated
>>>>700000 lines of code in final products. Final decision - C++.
>>>
>>>I'm surprised they'd trade const for all the other safety features, such
>>>as
>>>array overflow checking, guaranteed initialization, DbC, etc.
>
> hi,
>
> I may be missing the obvious, but isn't there a lot
> of constness that you can achieve with mode in parameters?
>
>
> georg

Passing a pointer, reference or array as 'in' will not prevent you from changing the contents of the thing pointed to, referred to, ... or arrayed to :-)

Ben Hinkle wrote:

>>I may be missing the obvious, but isn't there a lot
>>of constness that you can achieve with mode in parameters?
> 
> Passing a pointer, reference or array as 'in' will not prevent you from changing the contents of the thing pointed to, referred to, ... or arrayed to :-)

For what its worth, it _will_ protect the pointer itself.

If you want to change the pointer or the .ptr/.length,
you need to use the mode out for any such parameters:

void foo(char[] s) // "in"
{
  s ~= "foo"; // does nothing
}

void bar(inout char[] s) // "out"
{
  s ~= "bar"; // adds to string
}

Neither declaration _prevents_ you from changing s[],
but you are supposed to use Copy-on-Write - as usual.

--anders

"Walter" <newshound@digitalmars.com> wrote in message news:da8bdq$t7o$1@digitaldaemon.com...
>
> "Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:da7n5u$fqr$1@digitaldaemon.com...
>>
>> "Walter" <newshound@digitalmars.com> wrote in message news:da5l1t$9da$1@digitaldaemon.com...
>> > I'm surprised they'd trade const for all the other safety features,
>> > such
>> > as
>> > array overflow checking, guaranteed initialization, DbC, etc.
>>
>> All these and couple of things more was the main reason why we decided to consider D as a primary development language. (Harmonia was a proof of concept actually)
>>
>> const and const references is a part of DbC and big one.
>> ( http://en.wikipedia.org/wiki/Design_by_contract and from
>> there go to
>> http://en.wikipedia.org/wiki/Const_correctness )
>> opAssign/ctor/dtor for C++ programmer is also huge these days.
>
> The main use for opAssign I've seen (and if one does opAssign, one must do
> ctor's, dtor's) is to implement reference counting, or some other
> mechanism
> for managing memory. What other huge uses are there for it?
>

1) Full group of smart pointers and RAII cases: auto_ptr, shared_ptr,
com_ptr
2) COW strings and arrays.

>
>> To be short: D has nice features but to convince somebody
>> to switch to it e.g. from C++, D shall demonstrate
>> that it:
>> 1) can handle most popular design patterns.
>> 2) has more features - simplifies development a lot.
>>
>> Currently D 'has more ...' part (and attractive enough) but has
>> no basic C++ features (mentioned above) - and the worst thing
>> that you even cannot emulate them in D in principle (physically).
>>
>> The same applied to Java and C# versus D.
>
> Java doesn't have const, nor does it have opAssign, nor scoped
> destruction,
> nor even structs. What's stopping you from making a Java.lang.String class
> in D?

As Java String is completely useless in D.
Anders already mentioned it.
You cannot return slice from it.

To be short as it is immutable it requires immutable slices. As all system and runtime functions require char[] then strictly speaking String is useless.

>
>
>> E.g. you cannot implement std::string C++ class in D.
>> Yes, you can do something close but you will not be able to use slices
> with
>> it.
>> This is making one of most attractible features worthless.
>>
>> There was multiple attempts to make string class in D but
>> all of them (without immutables and immutable slicing)
>> look unreliable for commercial software design.
>
> Can I ask exactly what feature is motivating a desire for a string class?
> Is
> it the desire to make immutable strings?
>
>> >> b) no mobile platform support (one not so big project but with strong
>> > mobile
>> >> demand in perspective) - C++
>> >
>> > I'm not sure what this means.
>>
>> There is no compiler proven to produce code for XScale
>> processors Windows CE (Mobile).
>
> Is there a gcc for it? If so, then one can make a gdc for it, though I
> admit
> that would probably not be an attractive idea for a team interested in
> building an app rather than a compiler.
>

I have only information about theoretical opprtunity
to make WinCE exuctables on WinCE. No practical
projects.

Would be nice if D can be compileable in abstract byte or P code.
To create a cross compiler using this code or just using some simple VM will
be cool
from portability point of view.

Carlos Santander wrote:
<snip>
> Pure curiosity: why don't you also include stats for DMDscript?

I've included stats for those 'groups I'm
currently subscribed to.  I don't (yet?) lack enough life to be looking through every 'group on the DM server.  But nobody'll stop you doing it yourself if you like.

> Also, what does LOLQ mean?

http://www.allmyfaqs.com/faq.pl?LOLQ

You can't blame me, I didn't coin the term.  And sadly that's now a ghost wiki, stuck in the read-only position....

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on
the 'group where everyone may benefit.

"Walter" <newshound@digitalmars.com> wrote in message news:da5l1u$9da$2@digitaldaemon.com...
>
> "Anders F Björklund" <afb@algonet.se> wrote in message news:da5h2g$3go$1@digitaldaemon.com...
>> Anyway, I don't _really_ have to decide - until next month or so... :-) Guess I will think it through on summer holidays, and see where it goes.
>
> Thanks for letting me know. But I think that the SWT project may be completed in the next month or so, and it may solve the GUI problem for you.
>

Sorry for persistence but something is telling me that without "const" solution Phobos will never be solid enough for enterprise(business) programming.

I wouldn't rely on SWT too. As it is already natively compileable then
motivation to use it outside of Java is pretty minor.
Having SWT (as any other GUI library) is good in general though.
But again (sorry) SWT needs Java runtime with String, Phobos
shall be rewritten from scratch, etc.

Any progress from Kris, btw?

"Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:dacd4j$1rjr$1@digitaldaemon.com...
>
> "Walter" <newshound@digitalmars.com> wrote in message news:da5l1u$9da$2@digitaldaemon.com...
> >
> > "Anders F Björklund" <afb@algonet.se> wrote in message news:da5h2g$3go$1@digitaldaemon.com...
> >> Anyway, I don't _really_ have to decide - until next month or so... :-) Guess I will think it through on summer holidays, and see where it
goes.
> >
> > Thanks for letting me know. But I think that the SWT project may be completed in the next month or so, and it may solve the GUI problem for you.
> Sorry for persistence but something is telling me that without "const" solution Phobos will never be solid enough for enterprise(business) programming.

Since other languages don't have const yet are solid for enterprise programming, I have a hard time understanding this.

> I wouldn't rely on SWT too. As it is already natively compileable then
> motivation to use it outside of Java is pretty minor.
> Having SWT (as any other GUI library) is good in general though.
> But again (sorry) SWT needs Java runtime with String, Phobos
> shall be rewritten from scratch, etc.
>
> Any progress from Kris, btw?

I think Kris is on vacation.

"Walter" <newshound@digitalmars.com> wrote in message news:damhf1$khh$1@digitaldaemon.com...
>
> "Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:dacd4j$1rjr$1@digitaldaemon.com...
>>
>> "Walter" <newshound@digitalmars.com> wrote in message news:da5l1u$9da$2@digitaldaemon.com...
>> >
>> > "Anders F Björklund" <afb@algonet.se> wrote in message news:da5h2g$3go$1@digitaldaemon.com...
>> >> Anyway, I don't _really_ have to decide - until next month or so...
>> >> :-)
>> >> Guess I will think it through on summer holidays, and see where it
> goes.
>> >
>> > Thanks for letting me know. But I think that the SWT project may be completed in the next month or so, and it may solve the GUI problem for you.
>> Sorry for persistence but something is telling me that without "const" solution Phobos will never be solid enough for enterprise(business) programming.
>
> Since other languages don't have const yet are solid for enterprise programming, I have a hard time understanding this.

"other languages don't have const"
All languages of enterprise programming level (whatever it means)
has concept of either immutable basic/builtin reference types (String,
DateTime) with
their immutabilty enforcement or have a concept of const. Either shalow or
deep.

From known to me languages, only VB has no such concept at all.

Java has immutability of primitive reference types but:

"as of  May 2004, support for const is the fourth most popular Java request
for enhancement."
(The first and third most popular requests (generics and covariant return
types) are addressed by the Java 1.5 language, and the second most popular
request is “Provide documentation in Chinese.”)
http://pag.csail.mit.edu/~mernst/pubs/ref-immutability-oopsla2004.pdf


>
>> I wouldn't rely on SWT too. As it is already natively compileable then
>> motivation to use it outside of Java is pretty minor.
>> Having SWT (as any other GUI library) is good in general though.
>> But again (sorry) SWT needs Java runtime with String, Phobos
>> shall be rewritten from scratch, etc.
>>
>> Any progress from Kris, btw?
>
> I think Kris is on vacation.
>
>