April 29, 2005
John Demme wrote:
> Looks like there's a copy from August 1st, 2004 on DSource.
> 

Also, John Fletcher wrote up some tips here:
http://www.prowiki.org/wiki4d/wiki.cgi?DwithSwig


> On Fri, 2005-04-29 at 09:17 +1200, Brad Beveridge wrote:
> 
>>John Demme wrote:
>>
>>>The link on the D links page yields a 404.  Where's Andy's site
>>>nowadays?
>>>
>>>Also, is there a tutorial for this?
>>>
>>>John Demme

-- 
jcc7
http://jcc_7.tripod.com/d/
April 29, 2005
"Vladimir" <kv11111@mail.ru> wrote in message news:d4tsjv$1ate$1@digitaldaemon.com...
> Walter wrote:
>
>>
>> "Vladimir" <kv11111@mail.ru> wrote in message news:d4qvmu$114p$2@digitaldaemon.com...
>>> Matthias Becker wrote:
>>>
>>> > Bad library, not even the basic collections you find everywhere. So D is unusable in any kind of project.
>>> >
>>> >
>>> > A few C++ programmers see things like built in hash-tables and ask why
>> the
>>> > languages is bloated with stuff like that, which could be done in the library and then don't even give it a try.
>>> That was my first feeling after reading intro on digitalmars site.
>> Benefits
>>> described here seems not convincingly for me.
>>
>> The text can always be improved. What would be a convincing intro be for you?
>
>
> First informative link from front page is a link to comparation table.
> First
> look at this table shows that D has more features than others. But more
> detailed look shows that many of this features are not missing in other
> languages but raser implemented as libraries. Reasons for doing it in
> compiler are not described here.
>
> It's not obvious that moving a big part of library into compiler is good.
> Many people even convinced that this is evil, and have a reasons for it.
> So, if doing so, *very* *good* description of it's benefits must be
> written
> and placed just beside saying thad D has built-in dynamic and assosiative
> arrays. Without it a lot of C/C++ programmers just stop reading here.
>
> The most confusing section is about arrays. Reading page "D Strings vs C++
> Strings" which is linked from here one can agree
> that C++ STL library is far from ideal, and some changes to compiler (such
> as adding overloadable ~ operator) are also helpful, but there is no
> reason
> to built-in library into compiler.
> As for me, more convincing points is possible optimizations, more standard
> implementation (no more difference between STL string, QT QString, and
> many
> others), reference semantics, but these all are at the bottom of the page.
>
> Absence of "How Garbage Collection Works" part is also bad. For many C/C++
> programmers GC is associated with java/C# and VMs which are slow. Section
> "How Garbage Collection Works" is the only chance to be convinces that
> this
> really can be not-so-slow (especially for those who does not belive
> advertisements). May be adding this link:
> http://www.iecc.com/gclist/GC-faq.html
> and even this:
> ftp://ftp.cs.utexas.edu/pub/garbage/gcsurvey.ps
> would be helpful.

I pretty much agree that the D web site could use more description for the pros and cons for certain design decisions. The sections comparing D with other languages could have a FAQ all its own that gives the rationale behind the decisions. We've had thread after thread about certain decisions and if Walter explained himself just once (or sometimes "at all") on the web site it would help stream-line the newsgroup discussion and it would help people coming from other languages understand the factors that led to the current design. Instead of this "rationale" page being aimed at pushing D it would take a balanced view of the issue and explain why the decision in D was what it was. It would help give a less "rah-rah" feel to the comparisons with other languages and make it more informative.


April 29, 2005
>> /// @brief Struct with reference.
>> ///
>> /// Dear user. Please use only reference types
>> /// (objects or pointers) for T. Thank you.
>> ///
>> struct RefTo(T)
>> {
>>    T reference;
>> }
>
> You can build that restriction into the template!
>
> struct RefTo(T:Object)
> {
>     T reference;
> }
>
> struct RefTo(T: T*)
> {
>     T* reference;
> }
>
>     RefTo!(int *) X;    // works
>     RefTo!(int) Y;    // fails

Yes, but it is annoying for larger templates to define it twice if most of the functions are the same. But one could use a "restricting sub-template":


template UseOnlyPointersForRefTo(T : Object)
{}

template UseOnlyPointersForRefTo(T : T*)
{}

struct RefTo(T)
{
private:
  T m_data;

  // Dear user: If this fails, then you did not use an Object or
  // a pointer as type T.
  mixin UseOnlyPointersForRefTo!(T);

public:
  // Lots of lengthy functions...
}


By the way, mixins are great!

Ciao
uwe
April 29, 2005
Ben Hinkle wrote:
> "Vladimir" <kv11111@mail.ru> wrote in message news:d4tsjv$1ate$1@digitaldaemon.com...
...
>>>The text can always be improved. What would be a convincing intro be for
>>>you?
>>
>>
>>First informative link from front page is a link to comparation table. First
>>look at this table shows that D has more features than others. But more
>>detailed look shows that many of this features are not missing in other
>>languages but raser implemented as libraries. Reasons for doing it in
>>compiler are not described here.

...

>>Absence of "How Garbage Collection Works" part is also bad. For many C/C++
>>programmers GC is associated with java/C# and VMs which are slow. Section
>>"How Garbage Collection Works" is the only chance to be convinces that this
>>really can be not-so-slow (especially for those who does not belive
>>advertisements). May be adding this link:
>>http://www.iecc.com/gclist/GC-faq.html
>>and even this:
>>ftp://ftp.cs.utexas.edu/pub/garbage/gcsurvey.ps
>>would be helpful.
> 
> 
> I pretty much agree that the D web site could use more description for the pros and cons for certain design decisions. The sections comparing D with other languages could have a FAQ all its own that gives the rationale behind the decisions. We've had thread after thread about certain decisions and if Walter explained himself just once (or sometimes "at all") on the web site it would help stream-line the newsgroup discussion and it would help people coming from other languages understand the factors that led to the current design. Instead of this "rationale" page being aimed at pushing D it would take a balanced view of the issue and explain why the decision in D was what it was. It would help give a less "rah-rah" feel to the comparisons with other languages and make it more informative. 

I think "if Walter explained himself just once (or sometimes 'at all') on the web site" vs. having the same argument on the newsgroup over-and-over again is an excellent point. Certainly some of the perpetual hot topics could be more thoroughly described in the web pages.

On the other hand, some people seem to start posting complaints after reading only a couple paragraphs (perhaps my perspective is screwed up since I spent so much time as a lurker before I started posting). I think we'll alway have some people who would rather start arguing about how everything about D is wrong before they read the whole spec, but it would be good if the specification could highlight more of the deep thinking that went into the design of D.

-- 
jcc7
http://jcc_7.tripod.com/d/
April 29, 2005
Ben Hinkle wrote:
>>I half agree and half disagree.  I think that Walter made a very good point when he said that copy constructors are trouble; you are making a similar point by saying that we don't want to pass objects by value.
>>
>>So why not just ban passing classes by value?  That is, the following code would be illegal:
>>class Foo {};
>>int myFunc(Foo pass_by_value) {...}
>>it would give an error:
>>ERROR: Class objects cannot be passed by value.
>>They must be passed by pointer instead.
>>
>>Likewise, any code that required copying a class by value would be illegal.  Offhand, I can think of:
>>* Class values as function parameters
>>* Class values as function return values
>>* Direct object assignments
> 
> That is an option but I think it would be one of last resort. A type should be usable by itself - if taking pointers to something is required in order to make it useful then that should be built into the type. Also by building reference semantics into object you avoid silly typedefs like
> typedef Window_t* Window;
> I dislike C/C++ code that hides pointers behind typedefs. The typedef only becomes usable when it has some obvious naming convention like WindowRef and at that point WindowRef is pretty much the same as Window_t* so why bother.

I agree, I hate those types of typedefs.  But aren't you advocating exactly that by advocating reference semantics?  What is the difference, from a practical point of view, between
	(In a value-semantics language)
	class Window_t {};
	typedef Window_t* Window;
and
	(In a reference-semantics language)
	class Window {};

Aren't we doing the same thing in both cases?
April 29, 2005
Uwe Salomon wrote:
>> Say that you want to store a pointer to a type in a template struct.  Do  you do this?
>>     struct RefTo(T) {
>>       T reference;
>>     }
>> which works for classes, or this
>>     struct RefTo(T) {
>>       T *pointer;
>>     }
>> which works for structs?  Sure, you can do specialized templates, but  that's a kludge to work around the problem, IMHO.
> 
> 
> You declare this:
> 
> /// @brief Struct with reference.
> ///
> /// Dear user. Please use only reference types
> /// (objects or pointers) for T. Thank you.
> ///
> struct RefTo(T)
> {
>   T reference;
> }
> 
> And then this:
> 
> class Klasse { ... }
> struct Struktur { ... }
> 
> RefTo!(Klasse) klasseRef;
> RefTo!(Struktur*) strukturRef;
> 
> Does even have the same semantics:
> 
> klasseRef.store(new Klasse);
> strukturRef.store(new Struktur);

Sure.  I didn't mean to imply that you could not.  But your solution then forces this complexity throughout all other types which use the template.  Say that you had some other templates:
	struct Foo(T) { RefTo!(T) ref; }
	struct Bar(T) { Foo!(T)   foo; }
	struct Baz(T) { Bar!(T)   bar; }
Now, you have to percolate the restriction all the way up to the Baz template.
April 29, 2005
Russ Lewis wrote:
> Don't get me wrong - I still use D all the time.  Except for work, I don't even touch C and C++ anymore.  But if I ever write D++, this will be one thing that I will change. :)

Sorry to break it to you, but someone has already written D++. In fact, it's already at version 4.1. ;)

Perhaps D# is still available as a name.


D++: http://www.pagemac.com/dpp/index.php


What is D++?

D++ is a scripting language programmed in Microsoft Visual Basic 6... you know what? I think I've already written this. Perhaps you should all the info on the about page, as it's far more detailed than this is going to get. (From the D++ FAQ)


(By the way, I just found out about D++ today due to its link at http://www.kochandreas.com/home/language/matrix.htm. I wonder how many more people might stumble upon D if it were listed.)

-- 
jcc7
http://jcc_7.tripod.com/d/
April 29, 2005
"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:d4u49n$1ioj$1@digitaldaemon.com...
> Ben Hinkle wrote:
>>>I half agree and half disagree.  I think that Walter made a very good point when he said that copy constructors are trouble; you are making a similar point by saying that we don't want to pass objects by value.
>>>
>>>So why not just ban passing classes by value?  That is, the following
>>>code would be illegal:
>>>class Foo {};
>>>int myFunc(Foo pass_by_value) {...}
>>>it would give an error:
>>>ERROR: Class objects cannot be passed by value.
>>>They must be passed by pointer instead.
>>>
>>>Likewise, any code that required copying a class by value would be
>>>illegal.  Offhand, I can think of:
>>>* Class values as function parameters
>>>* Class values as function return values
>>>* Direct object assignments
>>
>> That is an option but I think it would be one of last resort. A type
>> should be usable by itself - if taking pointers to something is required
>> in order to make it useful then that should be built into the type. Also
>> by building reference semantics into object you avoid silly typedefs like
>> typedef Window_t* Window;
>> I dislike C/C++ code that hides pointers behind typedefs. The typedef
>> only becomes usable when it has some obvious naming convention like
>> WindowRef and at that point WindowRef is pretty much the same as
>> Window_t* so why bother.
>
> I agree, I hate those types of typedefs.  But aren't you advocating
> exactly that by advocating reference semantics?  What is the difference,
> from a practical point of view, between
> (In a value-semantics language)
> class Window_t {};
> typedef Window_t* Window;
> and
> (In a reference-semantics language)
> class Window {};
>
> Aren't we doing the same thing in both cases?

To me the expectations are different. Since C/C++ doesn't have any reference-semantics classes hiding the reference behind a typedef is not expected. But in languages where references are implicit it becomes expected and so it is less of a problem (unless someone avoids classes and uses a struct where they should use a class or vice-versa). But I agree that it is true an identifier without any context doesn't give any more information about value/reference semantics in D than a typedef does in C++. So in C when I see a type without a ptr I assume it is value based and get annoyed when the typedef hides it but in D one can't assume the type is value based so I have to rely on a guess based on the name or look up the definition. Usually that's enough.


April 29, 2005
"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?
> --
> Derek
> Melbourne, Australia
> 28/04/2005 5:40:45 PM


April 29, 2005
"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.

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.

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.

I've always felt that D will be a credible alternative to
    1. C - more OO and built-in GC
    2. C++ - better templates, address some of its imperfections
(http://imperfectcplusplus.com <g>)
    3. Java - more expressive, better syntax, templates, doesn't
need a VM
    4. .NET - not vendor locked (or won't be), templates, doesn't
need a VM

I would think that at the moment it could credibly be said to have achieved 1, but is woefully failing on 2 because of significant fundamental defects in the language, and failing on 3 and 4 because of lack of libraries and IDEs/tools.

Since there's much resistance from Walter to acknowledge/fix the defects, and much apathy/nonchalence from most of the community about them, I think the likelihood of 2 ever being achieved is negligable. It's going to take a real shift in attitude which just isn't going to happen. I think Walter's ambitions would be better served

But I think that the only impediments to 3 and 4 are time, and getting to grips with the gripes - some of which are significant - with Phobos. As long as Phobos gets a proper redesign / reimplementation, such that it neatly, and orthogonally supports 1 programming (procedural, non-OO) and 3/4 programming (class-based, OO), then I see no reason why D cannot compete strongly on 3 / 4.

So, in summary:

    Will D beat (i.e. be a credible, practicable alternative to):

        Perl - no, because that's not its intent
        Python - no, because that's not its intent
        Ruby - no, because that's not its intent
        C - yes, apart from things that have to be minimally coupled
and maximally portable to any/all platforms. Big potential here
        C++ - no, because there's no effective desire/purpose to
address the many reasons why C++ programmers are better off sticking
where they are. Huge potential here, but would require huge effort.
Not going to happen this lifetime
        Java - yes, once comprehensive tools and libraries are
implemented. Big potential. Just a matter of time
        .NET - yes, once comprehensive tools and libraries are
implemented. Big potential. Just a matter of time. And if D.NET is a
commercial reality, it can be a takeover, and not a fight

For me, I can certainly live with the prospect of needing to know two compiled languages - C++ and D - and two scripting languages - Python and Ruby. (Speaking from a programming-as-fun perspective, that's almost ideal!) :-)

Thoughts?