www.digitalmars.com         C & C++   DMDScript  

D - Your feelings

reply Peter Paul Chase <bluefox overland.net> writes:
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.
Aug 18 2001
next sibling parent Jan Knepper <jan smartsoft.cc> writes:
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
Aug 18 2001
prev sibling next sibling parent "LuigiG" <ask.if iyou.need.it> writes:
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.
Aug 19 2001
prev sibling next sibling parent "Walter" <walter digitalmars.com> writes:
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.
Aug 18 2001
prev sibling next sibling parent reply "kaffiene" <kaffiene xtra.co.nz> writes:
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.
Aug 18 2001
parent "Walter" <walter digitalmars.com> writes:
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.
Aug 18 2001
prev sibling parent reply "Tim Sweeney" <tim epicgames.com> writes:
 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
Aug 19 2001
parent reply "Walter" <walter digitalmars.com> writes:
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.
Aug 19 2001
next sibling parent reply Peter Paul Chase <bluefox overland.net> writes:
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.
Aug 19 2001
parent reply Jan Knepper <jan smartsoft.cc> writes:
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
Aug 19 2001
next sibling parent reply "Brent Schartung" <bschartung home.com> writes:
This got me thinking...  Every object is derived from a common base object,
as in Java.  As long as D includes RTTI (run-time type ID), we can maybe
replace STL-style generic programming with something like

class Stack
{
    Object[] stk;
    ...
}

Then, since every object is a reference (and every reference is of identical
size), we could maybe say something like:

Stack.push_list( [ 3, "Str", 8-7.9384i, new Widget( ) ] );

(I'm assuming that push_list(obj [] ) pushes the contents of the list, not a
ref to the list.)

Unfortunately, this can waste a lot of space; suppose you wanted a stack of
'N' ascii's / chars; you'd have to have type info for each one of them!  For
this reason we should maybe add a syntax for specifying a substitution (?)
of Object with int's--for example--for a particular instance of the generic
type.  But if the stack, etc are defined for all native types (a daunting
task) in the D library, then maybe the Object[] approach is sufficient for
less common generics.

Reactions?




 class  _STLVirtual
 {
     protected :
         _STLVirtual ();

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

         // ...
 };
Aug 19 2001
parent reply "Taylor Gautier" <tgautier yahoo.com> writes:
The system you talk about is exactly how Java works.  The main issues with
it are lack of speed and lack of type-safety.

The C++ advocates will yell at you for this, because you have to downcast to
your expected type (speed), and you can basically put anything into this
stack (type-safety).

When I left the Java scene about 1.5 years ago, there was talk of
specialized types, or generic collections or something of that nature, don't
know what has happened to it since...

In Java, there is no way of creating a type-safe container.  That's because
there is no way of specifying generic code ala C++ templates, and that is
the crux of the whole template discussion currently raging on this newsgroup
(fun stuff :))

In C++, there is no way of writing the Java equivalent of the class you
describe, because there is no root class for all classes (such a pity).
(Ok, you can make a mix-in class using multiple inheritance, but that's
pretty ugly, and there is no standard for it).

I hope D can make some progress in alleviating these two situations, as
Java's method is definitely better for some things, and C++'s is better for
others.  Having to be tied down to one or another simply by choice of
language is distressing.

-t

"Brent Schartung" <bschartung home.com> wrote in message
news:9lp22q$2cq4$1 digitaldaemon.com...

 This got me thinking...  Every object is derived from a common base


object,

 as in Java.  As long as D includes RTTI (run-time type ID), we can maybe
 replace STL-style generic programming with something like

 class Stack
 {
     Object[] stk;
     ...
 }

 Then, since every object is a reference (and every reference is of


identical

 size), we could maybe say something like:

 Stack.push_list( [ 3, "Str", 8-7.9384i, new Widget( ) ] );

 (I'm assuming that push_list(obj [] ) pushes the contents of the list, not


a

 ref to the list.)

 Unfortunately, this can waste a lot of space; suppose you wanted a stack


of

 'N' ascii's / chars; you'd have to have type info for each one of them!


For

 this reason we should maybe add a syntax for specifying a substitution (?)
 of Object with int's--for example--for a particular instance of the


generic

 type.  But if the stack, etc are defined for all native types (a daunting
 task) in the D library, then maybe the Object[] approach is sufficient for
 less common generics.

 Reactions?




 class  _STLVirtual
 {
     protected :
         _STLVirtual ();

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

         // ...
 };
Aug 20 2001
parent reply "Angus Graham" <agraham_d agraham.ca> writes:
 In C++, there is no way of writing the Java equivalent of the class you
 describe, because there is no root class for all classes (such a pity).
 (Ok, you can make a mix-in class using multiple inheritance, but that's
 pretty ugly, and there is no standard for it).


Sure there's a root for all C++ classes:  void.
As a good programmer you wouldn't consider stuffing your containers with
void* pointers to various classes, then trying to determine what they are
when you take them out.  But that's just what you're talking about when you
fill containers with base classes and use RTTI to get them out.

Angus Graham
Aug 20 2001
parent reply Jan Knepper <jan smartsoft.cc> writes:
Well, ( void * ) would be very rough... (I indeed would rather use a base class
in that case), but hey... Why not???
Aug 20 2001
parent "Taylor Gautier" <tgautier yahoo.com> writes:
I stand corrected (2x) :)  I was thinking of base classes.

-t

"Jan Knepper" <jan smartsoft.cc> wrote in message
news:3B8170AD.C4EB3053 smartsoft.cc...

 Well, ( void * ) would be very rough... (I indeed would rather use a base


class

 in that case), but hey... Why not???
Aug 21 2001
prev sibling parent reply "Angus Graham" <agraham_d agraham.ca> writes:
 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.


Nor should it be in my opinion.  Every collection that could reasonably
support [] access does.  Every container that could reasonably support
push_back() does.  To try to design your containers so that they can be used
with no understanding of how they work is a mistake IMO.

Further, the user of a function that takes a collection could innocently
pass in a collection without realizing the function works totally
innappropriately with it.  Hey it compiles right?  And it would work until
you ran the program with a slightly larger dataset and it ground to a halt.


 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...


I'll take every thing at compile time I can possibly get.  I'd like the
program defined the minute I put fingers to keyboard.  Not years from now
when it's run.


Angus Graham
Aug 20 2001
parent Jan Knepper <jan smartsoft.cc> writes:
Angus Graham wrote:


 To try to design your containers so that they can be used with no
 understanding of how they work is a mistake IMO.


You think that does not happen with the current design? <g>

Trying to design containers in such a way that using them is equal is great in
IMHO. That way when the 'demand' to the container changes because of functional
changes to the code one could much easier change the type of container without
having to go through numerous sources files to change the container access
everywhere.


 Further, the user of a function that takes a collection could innocently
 pass in a collection without realizing the function works totally
 innappropriately with it.  Hey it compiles right?  And it would work until
 you ran the program with a slightly larger dataset and it ground to a halt.


The user can do the exact same thing with a function template...

template < class C > DoSomethingWithContainer ( C  &coll )
{
    for ( C :: iterator  i = coll.begin () ; i != coll.end () ; i++ )
        // whatever.
}

Of course when every container would have a [] operator it could happen that
when used wrongly accessing the contents through it would be very heavy on the
CPU... Well, don't you think users are using for ( begin (), end () ) on map's
to do a reverse lookup at all??? <g>


 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...


 I'll take every thing at compile time I can possibly get.  I'd like the
 program defined the minute I put fingers to keyboard.  Not years from now
 when it's run.


Sure, but at times it might be nice to be able to get/use run time polyphormism.
This is not even an option now.

Jan
Aug 20 2001
prev sibling parent reply Charles Hixson <charleshixsn earthlink.net> writes:
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.
 


I can't speak to Haskell.  It has a type inference system that I don't 
understand, but the sturcture of container classes is tremendously 
sensitive to the structure of the language.  Look at Ada component 
classes, Java component classes, Eiffel component classes.  Each is 
highly different from the other, and all are different from the STL, 
even though several of them were designed with full knowledge of the 
STL's existence, and also knowledge that STL aware programmers were a 
large segment of the folk they were trying to recruit.

Expect that D will use a different structure.  If it's better than C++, 
if it has a different structure for the template classes (or replaces 
them with generics), it will.  I couldn't tell you just how it will 
differ.  For one thing, it's not deterministic.  Eiffel has at least 3 
major variants, but nobody's been able to do a direct translation.
Aug 21 2001
parent reply "Angus Graham" <agraham_d agraham.ca> writes:
 I can't speak to Haskell.  It has a type inference system that I don't
 understand, but the sturcture of container classes is tremendously
 sensitive to the structure of the language.  Look at Ada component
 classes, Java component classes, Eiffel component classes.  Each is
 highly different from the other, and all are different from the STL,
 even though several of them were designed with full knowledge of the
 STL's existence, and also knowledge that STL aware programmers were a
 large segment of the folk they were trying to recruit.


Stepanov wrote the STL for Ada first.  IIRC from Stroustrup's "D&E of C++",
C++ STL is 1/10 the klocs of Ada's.


Angus Graham

Whoa, say that last sentence ten times fast.
Aug 21 2001
parent Charles Hixson <charleshixsn earthlink.net> writes:
Angus Graham wrote:

...
 
 Stepanov wrote the STL for Ada first.  IIRC from Stroustrup's "D&E of C++",
 C++ STL is 1/10 the klocs of Ada's.
 
 
 Angus Graham
 
 Whoa, say that last sentence ten times fast.
 


I haven't seen that, but you can do nearly anything in Ada if you work 
hard enough at it.  Still, a factor of 1:10 certainly implies that it's 
a much better fit to C++.
Aug 21 2001