Frequently in the D news group you reject ideas because they don't "feel right".  Respectfully submit that this is not a basis for informed decision.  printf doesn't "feel right" to me and never did.

If D cannot use the STL (or a wrapped version of the STL), not many
people will be using it.

Also--too many people are now used to stream I/O.

Peter Paul Chase wrote:

> Frequently in the D news group you reject ideas because they don't "feel right".

That's because 'D' is going to be written out of experience of writing compilers. I guess.

> Respectfully submit that this is not a basis for informed decision. printf doesn't "feel right" to me and never did.

Sorry, but the solution could be to design your own language and write your
own compiler.
By the way, as far as I understood printf is not going to be part of 'D',
it's just that 'D' is able to 'import' 'C' functions for which reason it can
use 'printf'.

> If D cannot use the STL (or a wrapped version of the STL), not many people
> will be using it.

People that demand 'STL' will nog be using 'D'. People that take C++ as a religion will not be using 'D'. Those people do not use Delphi, Java or Visual Basic either. Yet there are more Delphi, Java and Visual Basic users than there are C or C++ AFAIK.

As far as I understood 'D' is going to have templates.

> Also--too many people are now used to stream I/O.

My guess... People had to get used to stream I/O... They will get used to anything else...

HTH
Jan

There's nothing wrong with things that do or do not feel right -- Intuition
can play an important role in designing a language.
Besides, a lot of people are used to MFC; a lot of people are used to
templates;
and some people are probably not happy to give in operator overloading or
multiple inheritance;
if you start adding features based on what people are "used to", you'll end
up desiging C or C++; but oops, we already have them.
--Luigi

"Peter Paul Chase" <bluefox@overland.net> wrote in message news:3B7F027B.28B74646@overland.net...
> Frequently in the D news group you reject ideas because they don't "feel right".  Respectfully submit that this is not a basis for informed decision.  printf doesn't "feel right" to me and never did.
>
> If D cannot use the STL (or a wrapped version of the STL), not many
> people will be using it.
>
> Also--too many people are now used to stream I/O.
>
>

Peter Paul Chase wrote in message <3B7F027B.28B74646@overland.net>...
>Frequently in the D news group you reject ideas because they don't "feel right".  Respectfully submit that this is not a basis for informed decision.  printf doesn't "feel right" to me and never did.


I think the way a language looks and feels is important.

Doesn't it seem ironic that when someone says: "C++ is a messy language - let's clean it up" that everyone says "yes" then criticises the new approach because "D doesn't have feature X and lots of people use feature X in C++"

Look, anyone who is participating with this discussion is probably doing so because the D feature list appeals to them.  That feature list is itself a products of what just "feels right" to Walter.  I'd be upset if everything was non-neogtiable on the basis of how Walter feels, but it appears to me that he's taking advice when there's a good case for a feature.

Peter.

"Peter Paul Chase" <bluefox@overland.net> wrote in message news:3B7F027B.28B74646@overland.net...
> Frequently in the D news group you reject ideas because they don't "feel right".  Respectfully submit that this is not a basis for informed decision.  printf doesn't "feel right" to me and never did.
>
> If D cannot use the STL (or a wrapped version of the STL), not many
> people will be using it.
>
> Also--too many people are now used to stream I/O.
>
>

kaffiene wrote in message <9lnbua$1drl$1@digitaldaemon.com>...
>That feature list is itself a
>products of what just "feels right" to Walter.  I'd be upset if everything
>was non-neogtiable on the basis of how Walter feels, but it appears to me
>that he's taking advice when there's a good case for a feature.


I've gotten a lot of great ideas from bouncing D off of others, many of which are incorporated. The most difficult part of developing D is saying "no" to some obviously great features. In order to finish implementing it I have to be ruthless and brutal about the feature set.

An Ansi C++ committee delegate told me once how disappointed he was that some members were saying in effect to each other "vote for my feature and I'll vote for your feature." I wish to avoid that.

> Frequently in the D news group you reject ideas because they don't "feel right".  Respectfully submit that this is not a basis for informed decision.  printf doesn't "feel right" to me and never did.

Language syntax is a creative work, influenced by history and aesthetics. Making a language "feel right" is vital to its success!

> If D cannot use the STL (or a wrapped version of the STL), not many
> people will be using it.

Baloney!  STL is something only a C++ programmer could appreciate.

Witness that when STL is translated to a language with a more flexible type system (such as Haskell), it basically "disappears" into much simpler native language functionality -- and you realize that half of STL consists of workarounds for C++ limitations, while the other half consists of workarounds for STL's limitations.

STL-like techniques have no place whatsoever in a cleanly designed language.

-Tim

Tim Sweeney wrote in message <9lno18$1kmb$1@digitaldaemon.com>...
>Witness that when STL is translated to a language with a more flexible type system (such as Haskell), it basically "disappears" into much simpler
native
>language functionality -- and you realize that half of STL consists of
>workarounds for C++ limitations, while the other half consists of
>workarounds for STL's limitations.
>STL-like techniques have no place whatsoever in a cleanly designed
language.


I'm very interested in hearing more about this.

I seem to have touched a nerve--sorry.  I'm interested to learn that D will provide the functionality of the STL in some other form.  Quite an undertaking!



Walter wrote:

> Tim Sweeney wrote in message <9lno18$1kmb$1@digitaldaemon.com>...
> >Witness that when STL is translated to a language with a more flexible type system (such as Haskell), it basically "disappears" into much simpler
> native
> >language functionality -- and you realize that half of STL consists of
> >workarounds for C++ limitations, while the other half consists of
> >workarounds for STL's limitations.
> >STL-like techniques have no place whatsoever in a cleanly designed
> language.
>
> I'm very interested in hearing more about this.

Peter Paul Chase wrote:

> I seem to have touched a nerve--sorry.  I'm interested to learn that D will provide the functionality of the STL in some other form.  Quite an undertaking!

I read somewhere that there is being thought about integrating templates and
possibly STL... However, I personally think STL has a couple of design mistakes.
1.    The interface is not the same for all collections.
2.    There is no way to chose for compile time or runtime polyphormism. All it can
do now is compile time polyphormism which basically leaves the root of the original
C++ with runtime polyphormism...

Check some reading on news://forums.borland.com/borland.public.cppbuilder.language/ subject "D Programming Language spec"

Basically it comes down to that I think there should have been a design (simply)
like:

class  _STLVirtual
{
    protected :
        _STLVirtual ();

    public   :
        virtual        add    ( .. )    = 0;
        virtual        erase    ( ... )    = 0;
        virtual        begin    ( ... )    = 0;
        virtual        end        ( ... )    = 0;

        // ...
};

class  _STLEmpty
{
};


Than:

template < class T, class Base >  class  vector : public  Base
{
    public    :
        add ( .. );
        erase ( ... );
        begin ( ... );
        end ( ... );
};

Than if you want compile time polymorphism:

// Should not really hurt as _STLEmpty is empty, i.e. does not have any (virtual)
members.
vector < int, _STLEmpty >        array0;

If you want run-time polymorphism:

vector < int, _STLVirtual >        array1;
list < int, STLVirtual >              list1;


void DoSomethingWith ( _STLVirtual  *coll )
{
    // ...
}

Do you want extre members in run-time polyphormism. Derive a class from _STLVirtual and use that as base class:

class  My_STLVirtual : public _STLVirtual
{
    public    :
        virtual        MyExtraMembe    ( ... );
};


vector < int, My_STLVirtual >        array2;
list < int, My_STLVirtual >            list2;

void  DoSomethingWithMyStuff ( My_STLVirtual  *coll )
{
    // ...
}

Of course with STL as it has been designed this is a problem as equally named
members in the different collection templates have different parameters and return
types. However I think this could have been resolved in the design...
Having the same return types and parameters for compile time polymorphism only
would make things easier for implementation anyways... (Than you don't have to
think... I geezh how did I get the data out of this one?!)

Jan