"jicman" <jicman_member@pathlink.com> wrote in message news:d51e6c$1mcf$1@digitaldaemon.com...
>
> Matthew says...
>>
>>
>>"Derek Parnell" <derek@psych.ward> wrote in message news:2ddk2n5oayb6$.1lycbdczpdp9w$.dlg@40tude.net...
>>> On Wed, 27 Apr 2005 09:26:18 +1000, Matthew wrote:
>>>
>>>> I've read a couple of things recently that've indicated that
>>>> D's
>>>> not
>>>> taken seriously by the C++ world.
>>>
>>> I'm not in the C++ plus world, nor are my professional
>>> colleagues,
>>> but I'm
>>> wondering if D's target audience is not the current
>>> C/C++/C#/Java
>>> crowd.
>>> Instead, might it be found in the Perl, Python, Ruby, Euphoria,
>>> and
>>> total-newbie groups that have not been exposed to the foibles of
>>> the 'C'
>>> legacy, and are looking for speed, power, and simplicity?
>>>
>>> Would attempting to "sell" to this set of people be a useful exercise?
>>
>>Without built-in regex, it's not going to sell as an alternative
>>to
>>Perl or Ruby.
>
> With all due respect, what is so hard about,
>
> import std.regexp;
>
> That's all one needs.  Of course, the syntax is different, but
> it's a few
> minutes of learning it and it won't be that hard.
>
>
>>
>>And I can't see how it's ever going to be a credible alternative
>>to
>>Python, which takes simplicity and usability to the extreme and,
>>perhaps more importantly, a wealth of libraries.
>
> Well, hmmmm, let's see: speed, stand-along executable, did I mentioned speed?

Speed is very important, when it's important. But often it's not, in which case usability, ease-of-use, libraries, etc. is more important. A lot of scripting involves such cases, so unless D can compete on ease of use and libs, such programming is not going to attract D use.

"Walter" <newshound@digitalmars.com> wrote in message news:d51efr$1mj1$1@digitaldaemon.com...
>
> "Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:d51c57$1kir$1@digitaldaemon.com...
>>
>> "Walter" <newshound@digitalmars.com> wrote in message news:d4vlsg$4l7$2@digitaldaemon.com...
>> >
>> > "Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:d4ud9f$1qrc$1@digitaldaemon.com...
>> >> I just don't see D as an alternative to scripting languages.
>> >> DMDScript might, but I've not (yet) used it, and don't really
>> >> know
>> >> anything about it.
>> >
>> > DMDScript is an implementation of ECMA262 (i.e. javascript). It
>> > has nothing
>> > to do with D, other than being implemented in D.
>>
>> nothing?
>>
>> I thought it shared a lot of the syntax, char[] and whatnot? Oh well, I stand corrected.
>
> The syntax has superficial similarities, both being curly brace
> languages,
> but the D language has as much in common with the DMDScript
> language as C++
> does to Ruby.

What, they're both brilliant?? :-)

On Mon, 2 May 2005 18:33:54 +1000, Matthew wrote:


[snip]

>> Well, hmmmm, let's see: speed, stand-along executable, did I mentioned speed?
> 
> Speed is very important, when it's important. But often it's not, in which case usability, ease-of-use, libraries, etc. is more important. A lot of scripting involves such cases, so unless D can compete on ease of use and libs, such programming is not going to attract D use.

Agreed. And that is the same as saying that when the situation arises that a scripting language is not (or no longer) suitable, then D ought to be an attractive alternative.

It seems that you are both in agreement, but with different emphasis.

-- 
Derek Parnell
Melbourne, Australia
http://www.dsource.org/projects/build v2.05 is now available. 02/May/2005
3/05/2005 7:21:22 AM

In article <d4tod4$16rb$1@digitaldaemon.com>, Vladimir says... ..
>One can forget about COW technology - compiler will say nothing.
>(BTW, can one write a transparent COW wrapper for dynamic arrays in D ? In
>C++ this is easy).
>Just imagine how many work must be done to convert existing struct into
>class or vise versa. And compiler will never help here.
..
>          Vladimir

Would anyone be interested in a COW array class?  I've written one.  It was part of a discontinued STL like code base.  (This is why I wanted opIndexMutable()). I stopped working on after I saw that MinTL does most of the same work plus a lot more, but this class (called "BrittleVector") was not duplicated by MinTL AFAIK.

It just keeps a bit and does .dup on non-read-only operations.  I think it is safe for many or all combinations of slice sharing.  But it is very conservative about copying -- it copies whenever a change may happen.

You can do this:

BrittleVector array1 = ..;

(fill arrays)

BrittleVector array2 = new BrittleVector(array2);

while(array2[0] == 0)
array2.popFront()

while(array2[array2.length-1] == 0)
array2.popBack()

if (array2[0] == 1) {
// No duplication unless you get here.
array2.pushBack(array2[0]);
}

Insert, erase, etc are implemented, plus pretty thorough unit testing.

(Ben, would you like this for MinTL?  Or anyone else writing a collection..)

Kevin

"Kevin Bealer" <Kevin_member@pathlink.com> wrote in message news:d59q6m$18o1$1@digitaldaemon.com...
> In article <d4tod4$16rb$1@digitaldaemon.com>, Vladimir says... ..
>>One can forget about COW technology - compiler will say nothing.
>>(BTW, can one write a transparent COW wrapper for dynamic arrays in D ? In
>>C++ this is easy).
>>Just imagine how many work must be done to convert existing struct into
>>class or vise versa. And compiler will never help here.
> ..
>>          Vladimir
>
> Would anyone be interested in a COW array class?  I've written one.  It
> was part
> of a discontinued STL like code base.  (This is why I wanted
> opIndexMutable()).
> I stopped working on after I saw that MinTL does most of the same work
> plus a
> lot more, but this class (called "BrittleVector") was not duplicated by
> MinTL
> AFAIK.
>
> It just keeps a bit and does .dup on non-read-only operations.  I think it
> is
> safe for many or all combinations of slice sharing.  But it is very
> conservative
> about copying -- it copies whenever a change may happen.
[snip]
> (Ben, would you like this for MinTL?  Or anyone else writing a collection..)

I think it's too inefficient to dup on every modification so for now MinTL will assume users manage their own COW if needed. I'll keep it in mind, though.

In article <d5apen$273n$1@digitaldaemon.com>, Ben Hinkle says...
>
>
>"Kevin Bealer" <Kevin_member@pathlink.com> wrote in message news:d59q6m$18o1$1@digitaldaemon.com...
>> In article <d4tod4$16rb$1@digitaldaemon.com>, Vladimir says... ..
>>>One can forget about COW technology - compiler will say nothing.
>>>(BTW, can one write a transparent COW wrapper for dynamic arrays in D ? In
>>>C++ this is easy).
>>>Just imagine how many work must be done to convert existing struct into
>>>class or vise versa. And compiler will never help here.
>> ..
>>>          Vladimir
>>
>> Would anyone be interested in a COW array class?  I've written one.  It
>> was part
>> of a discontinued STL like code base.  (This is why I wanted
>> opIndexMutable()).
>> I stopped working on after I saw that MinTL does most of the same work
>> plus a
>> lot more, but this class (called "BrittleVector") was not duplicated by
>> MinTL
>> AFAIK.
>>
>> It just keeps a bit and does .dup on non-read-only operations.  I think it
>> is
>> safe for many or all combinations of slice sharing.  But it is very
>> conservative
>> about copying -- it copies whenever a change may happen.
>[snip]
>> (Ben, would you like this for MinTL?  Or anyone else writing a collection..)
>
>I think it's too inefficient to dup on every modification so for now MinTL will assume users manage their own COW if needed. I'll keep it in mind, though.

Sharing sets a "brittle" bit in both objects.  It only does a dup if the shared bit is set, and duping clear the bit.  If you then modify each object ten times, you get two .dup() operations, not twenty.  A true COW implementation would probably keep a refcount and do only one dup, though.  In my scheme the original array becomes garbage if you modify both objects.

You could probably implement this from this description more easily than reading all my code.

My design was by analogy with the "std.string" functions (ie toupper) that return the original if the data is already uppercase.  You can "copy" a brittle vector almost for free, then pass it into a function, and it only dups it if the data actually changes.

This would be good for "delete_if" type operation.

(Unfortunately, "foreach()" is a mutable operation in D.)

Kevin

I recently discovered the D web site and the language looks really nice, although I haven’t tried it yet. There are a couple of reasons why I’d be hesitant to use it at my job.

1. I’d be expecting the programmers around me as well as those who come after me
and maintain my code to learn a new language (although it is similar). Everyone
knows C/C++. If someone needs to maintain my C/C++ code, they can jump right in.
But before they maintain my D code they’d have to learn it, as well as install a
new set of tools on their computer. And they’d probably be griping the whole
time, “Why couldn’t he just use C++. Grrr.” Granted, there’s nothing D can do
about this. It’s just the way it is.

2. “Nobody ever got fired for buying IBM”. I may choose to use D in my company.
But if anything goes wrong and there’s some problem or limitation that would not
have occurred if I had used C++ in the first place, it won’t go down well. But
the same is not true in the reverse case. If I use C++ and there is a problem or
limitation, no one will blame me for choosing C++. In fact, this seems like the
same issue all over again as it was with C and C++. Way back when most people
were using straight C, it was hard to get C++ accepted. If you finished your C++
program and it ran at all slower than a C version, you’d risk getting chided for
“those virtual functions that just slow things down”, or some such stuff.

I think both of these issues are about the critical mass effect. D would be more attractive if lots of people were already using it. If you can get to that critical mass, then it snowballs.

If D had a decent IDE it would be nice. I have to say I do like some things about the Visual Studio IDE. I like how it can take me to the definition of a variable, or how it can show me the type when I hover my mouse over it. But even if D had a nice IDE, that would still be a side issue.

I don’t care if the D web page is slick or not.


Jim


In article <d4mioc$2lgm$1@digitaldaemon.com>, Matthew says...
>
>I've read a couple of things recently that've indicated that D's not taken seriously by the C++ world. I am wondering whether this is true, since it's certainly not the impression that I've had from the people I've spoken with about it, most of whom are not using it now, but are definitely interested in doing so in the future; the D-curious, if you like?
>
>I'm interested to hear from people what their friends/colleagues/etc. think about D, especially in terms of whether they would be willing to use it come 1.0.
>
>I'm also interested to hear of any specific must-haves that such people have expressed.
>
>Please, everyone, don't turn this thread into what _you_ think about D, or what _you_ think should be in 1.0. We have a pretty good feel for what D-philes think already.
>
>Cheers
>
>Matthew
>
>

"Walter" <newshound@digitalmars.com> wrote in message news:d4uhr2$1uhm$2@digitaldaemon.com...
>
>
> Shouldn't search work better than an index?
>

Actually, search and Index tend to complement each other...
because the search can help find things not listed in the Index or not listed as expected...
and the index can give a quick overview of what's available without having to first know what to search for.

TZ

"Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:d4v7ib$2gbk$1@digitaldaemon.com...
> > to say it "doesn't compete with C++" is somewhat irrelevant since the marketplace will obviously consider anything that calls itself a successor to C and competing with Java/C# as competing with C++ as well.
>
> My point was that D is not now, and is unlikely to become, any more credible/relevant an alternative to C++ than it is Perl/Python/Ruby.
>
> Furthermore, by fostering, or at least not rejecting, the notion that it _is_ a credible/relevant alternative to C++ is detrimental to its chances of success, since people can reasonably criticise its _fundamentals_ wrt C++, which I don't believe is the case with Java/.NET.
>
> Of course, I may be wrong, as I'm not exactly an expert in Java / .NET. But I'm not aware of any great negative relativism from Java/.NET aficionados, other than that the libraries and tools are deficient.
>
> Thus, my proposition that D is it stands as a language, has no great impediment to being a competitor for C and Java/.NET given appropriate libraries/documentation/tools, which cannot be said for C++.
>
> > We might as well be honest and say *how* it competes with C++ and where one might want to choose one over the other. To me the downside of the current web pages is that it tends to be very rah-rah for D and ignores any counter-argument. I wouldn't be surprised if C++ programmers responded better if their specific concerns were addressed (or at least acknowledged) on the site.
>
> This is very true, but I think that's not going to bring in more C++ people into the inner circle. It might serve to get them past the front door, but they're still as likely to wander off in a huff of disdain, perhaps just a little more informed in their criticism.
>
>
>
> My point about perspective is that discussion of D as an alternative to C++ should either stop, or be markedly downplayed, since this seems to be given very little credit in the wider C++ community (and maybe not all that much within the D community). Rather we should focus on genuine areas of specific competitiveness - i.e. given D with excellent libraries/docs/tools, why would one use .NET? - and on promoting D in its own right, which is at once both more optimistic and less fallacious.
>

I agree that there should be less focus on (and reliance on) D's relation to C and C++, and
more focus on D as a language in and of itself, viable as an alternative to
any programming language currently in existance.

I also feel that D needs to have more focus on it's not only being being flexible enough work well with other languages, but also being powerful enough to stand on it's own.

(are we there yet?)

TZ

I'm not sure if this is relevant here, but I am an expert .NET developer and I have used C++ (through Microsoft's managed extensions with the Visual C++ compiler) with the .NET framework.  Can the same be done with D or the D compiler?  If so, it would actually make D the language of choice for .NET development, at least in my book.  Or at least until the second version of C# comes out...

By the way, I think it can be done and wouldn't be that difficult to do.  It's just a matter of who has the time to do it.  But I think a lot of people would be interested in .NET development with the D language................

Or dare I say......................

The D# language!!!!!!!!!!!!

;D

PS-
If anyone wants to attempt this, look into .NET's 'System.CodeDOM' namespace.

In article <d72so5$hch$1@digitaldaemon.com>, TechnoZeus says...
>
>"Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:d4v7ib$2gbk$1@digitaldaemon.com...
>> > to say it "doesn't compete with C++" is somewhat irrelevant since the marketplace will obviously consider anything that calls itself a successor to C and competing with Java/C# as competing with C++ as well.
>>
>> My point was that D is not now, and is unlikely to become, any more credible/relevant an alternative to C++ than it is Perl/Python/Ruby.
>>
>> Furthermore, by fostering, or at least not rejecting, the notion that it _is_ a credible/relevant alternative to C++ is detrimental to its chances of success, since people can reasonably criticise its _fundamentals_ wrt C++, which I don't believe is the case with Java/.NET.
>>
>> Of course, I may be wrong, as I'm not exactly an expert in Java / .NET. But I'm not aware of any great negative relativism from Java/.NET aficionados, other than that the libraries and tools are deficient.
>>
>> Thus, my proposition that D is it stands as a language, has no great impediment to being a competitor for C and Java/.NET given appropriate libraries/documentation/tools, which cannot be said for C++.
>>
>> > We might as well be honest and say *how* it competes with C++ and where one might want to choose one over the other. To me the downside of the current web pages is that it tends to be very rah-rah for D and ignores any counter-argument. I wouldn't be surprised if C++ programmers responded better if their specific concerns were addressed (or at least acknowledged) on the site.
>>
>> This is very true, but I think that's not going to bring in more C++ people into the inner circle. It might serve to get them past the front door, but they're still as likely to wander off in a huff of disdain, perhaps just a little more informed in their criticism.
>>
>>
>>
>> My point about perspective is that discussion of D as an alternative to C++ should either stop, or be markedly downplayed, since this seems to be given very little credit in the wider C++ community (and maybe not all that much within the D community). Rather we should focus on genuine areas of specific competitiveness - i.e. given D with excellent libraries/docs/tools, why would one use .NET? - and on promoting D in its own right, which is at once both more optimistic and less fallacious.
>>
>
>I agree that there should be less focus on (and reliance on) D's relation to C and C++, and
>more focus on D as a language in and of itself, viable as an alternative to
>any programming language currently in existance.
>
>I also feel that D needs to have more focus on it's not only being being flexible enough work well with other languages, but also being powerful enough to stand on it's own.
>
>(are we there yet?)
>
>TZ
>
>

-Sam
sam987883