www.digitalmars.com         C & C++   DMDScript  

D - D / tutorial / stdlib / killer app

reply Helmut Leitner <leitner hls.via.at> writes:
A few general thoughts about the current situation.

Walter and Burton do an admirable job to push D forward. But to help
them we (all others) have to find ways to contribute code and collaborate 
more effectively.

To use D it's nice to have this tight C connection, but in the long
run it will be an hindrance to make C popular. You can't write a nice
and easy tutorial if you have to fall back to printf or scanf. So there 
should a line of thought that targets the non-C-D-beginner. In the end 
there must be something like (pseudocode):
   Print("Enter Date: "); 
   Input(date); 
   Push(DataArray,date);
   Print("Today: ",date);
Only easy things become popular. 

The same is true for the stdlib. D needs the gui (dig), ide, print,
image, scan, cgi, database and a miriad of other modules. But it won't 
help much if this functionality is distributed among many libraries
and written in many different styles. We should find a way to establish
a D library style, that's powerful and unbloated. It doesn't make sense
to go the Java and C# way to just put anything in that's thinkable. 
(I specially remember the Java class to read numbered lines from a stream)
We don't have Sun or Microsoft resources to go this "brute force" way.
(And I don't think its programmer-friendly anyway)

It seems that D would lend itself well to a mixed OO style, where only
the core functionality is OO, while other functions explicitely pass
the main object and can be stripped by the linker (avoiding bloat).
For example, if you do user interfaces and report generations you handle
all types of rectangular areas (frames) and dependencies. I think my
C RECT module contains about 80 functions to split, join, change and
position rectangles. It doesn't make sense to add functions to libraries
(to classes) when they increase the footprint of applications using the
libraries. D has a way around this, but no established style to make 
good use of it. This hasn't been discussed.

Even the current Phobos library seems already a rather inconsistent 
mix of styles. I also think that the duplication of C functions in
D libraries is a bad habit. We don't live under the 6/8 char name
restriction anymore and should use readable names consistently. 
A way to do this would be introduce a common vocabulary of names
with a defined meaning, so that a user/programmer can rely upon
that any image function will have "Image" (and not "Picture",
"Pict" or "Img") in its name. A while ago I did quite an amount
of work about this type of consistent vocabularies. Typically its hard
to get people to give up their "freedom" to name functions the way 
they like - but its the only way to get consistency into large APIs.

The production of good apps (killer apps) will also work better when the
developments can be coordinated to build the apps and the core library
at the same time, avoiding redundant development work. This would need
a repository where developers can directly contribute without creating 
unstable systems. This would need some kind of automated build and test
system. But I've no idea how this could be accomplished.

-- 
Helmut Leitner    leitner hls.via.at
Graz, Austria   www.hls-software.com
Jul 30 2003
next sibling parent reply Frank Wills <name host.com> writes:
Helmut,
I think that in essence you are right.
  - If we want to see D be truely successful in
the mainstream we need to create a development
environment that covers all of the bases.
  - We want to do this in a standardized way,
perhaps creating a 'D' way of doing things that
extends and fulfills the philosophy of the D
language. This we can't do successfully if we
contribute in a disjointed manner. I agree
with that.
  - To do this we certainly need to work together
to define this D development environment, standard,
and philosophy. From there we can define the
tool and environment components, gui library, ide,
image, scan, cgi, database, and etcetera.
  - Personally, D is what I have been looking
forward to seeing someone develop, Walter has
done a lot by giving us this, and I think it
would certainly be worth the effort to pitch
in as a team to achieve these goals.
  - As a thought, we need a website that can
project what we formalize, decide, discuss,
and accomplish as we go (assuming we reach
a concensus along these lines and work towards
something like this.)
  - As a final thought, all of this would require
a lot of work for some time. What persuades me
is that after years of watching and waiting to
see what would follow C and C++, the solutions
that the major companies have come up with
fall short of what I had hoped for, and deviate
to some extent as well, such as with the use
of VMs and massive resource requirements. So,
given that these companies are not heading
in the direction that we really want, I
think it may truely be worthwhile to make
the committment to work together towards
such a goal.

Helmut Leitner wrote:
 A few general thoughts about the current situation.
 
 Walter and Burton do an admirable job to push D forward. But to help
 them we (all others) have to find ways to contribute code and collaborate 
 more effectively.
 
 To use D it's nice to have this tight C connection, but in the long
 run it will be an hindrance to make C popular. You can't write a nice
 and easy tutorial if you have to fall back to printf or scanf. So there 
 should a line of thought that targets the non-C-D-beginner. In the end 
 there must be something like (pseudocode):
    Print("Enter Date: "); 
    Input(date); 
    Push(DataArray,date);
    Print("Today: ",date);
 Only easy things become popular. 
 
 The same is true for the stdlib. D needs the gui (dig), ide, print,
 image, scan, cgi, database and a miriad of other modules. But it won't 
 help much if this functionality is distributed among many libraries
 and written in many different styles. We should find a way to establish
 a D library style, that's powerful and unbloated. It doesn't make sense
 to go the Java and C# way to just put anything in that's thinkable. 
 (I specially remember the Java class to read numbered lines from a stream)
 We don't have Sun or Microsoft resources to go this "brute force" way.
 (And I don't think its programmer-friendly anyway)
 
 It seems that D would lend itself well to a mixed OO style, where only
 the core functionality is OO, while other functions explicitely pass
 the main object and can be stripped by the linker (avoiding bloat).
 For example, if you do user interfaces and report generations you handle
 all types of rectangular areas (frames) and dependencies. I think my
 C RECT module contains about 80 functions to split, join, change and
 position rectangles. It doesn't make sense to add functions to libraries
 (to classes) when they increase the footprint of applications using the
 libraries. D has a way around this, but no established style to make 
 good use of it. This hasn't been discussed.
 
 Even the current Phobos library seems already a rather inconsistent 
 mix of styles. I also think that the duplication of C functions in
 D libraries is a bad habit. We don't live under the 6/8 char name
 restriction anymore and should use readable names consistently. 
 A way to do this would be introduce a common vocabulary of names
 with a defined meaning, so that a user/programmer can rely upon
 that any image function will have "Image" (and not "Picture",
 "Pict" or "Img") in its name. A while ago I did quite an amount
 of work about this type of consistent vocabularies. Typically its hard
 to get people to give up their "freedom" to name functions the way 
 they like - but its the only way to get consistency into large APIs.
 
 The production of good apps (killer apps) will also work better when the
 developments can be coordinated to build the apps and the core library
 at the same time, avoiding redundant development work. This would need
 a repository where developers can directly contribute without creating 
 unstable systems. This would need some kind of automated build and test
 system. But I've no idea how this could be accomplished.
 

Jul 30 2003
parent Helmut Leitner <helmut.leitner chello.at> writes:
Frank Wills wrote:
   - As a final thought, all of this would require
 a lot of work for some time. What persuades me
 is that after years of watching and waiting to
 see what would follow C and C++, the solutions
 that the major companies have come up with
 fall short of what I had hoped for, and deviate
 to some extent as well, such as with the use
 of VMs and massive resource requirements. So,
 given that these companies are not heading
 in the direction that we really want, I
 think it may truely be worthwhile to make
 the committment to work together towards
 such a goal.

I completely agree. -- Helmut Leitner leitner hls.via.at Graz, Austria www.hls-software.com
Jul 31 2003
prev sibling next sibling parent "Riccardo De Agostini" <riccardo.de.agostini email.it> writes:
"Helmut Leitner" <leitner hls.via.at> ha scritto nel messaggio
news:3F279BAE.41C709AD hls.via.at...
 A few general thoughts about the current situation.
 [...]
 To use D it's nice to have this tight C connection, but in the long
 run it will be an hindrance to make C popular. You can't write a nice
 and easy tutorial if you have to fall back to printf or scanf. So there
 should a line of thought that targets the non-C-D-beginner.

200% right IMHO.
 The same is true for the stdlib. D needs the gui (dig), ide, print,
 image, scan, cgi, database and a miriad of other modules. But it won't
 help much if this functionality is distributed among many libraries
 and written in many different styles. We should find a way to establish
 a D library style, that's powerful and unbloated. It doesn't make sense
 to go the Java and C# way to just put anything in that's thinkable.

I don't agree completely: while a D library style is surely one of the most important (and urgent) things to consider, I wouldn't spend time and energy on GUI, print, etc. etc. until we have that style in a more-than-just-draft form. As developing libraries of some kind is important in order to refine the library style specs, why not concentrate on replacing stdio and other C heritage, for now? (Mind that "now" could mean a short time if enough people take it seriously).
 It seems that D would lend itself well to a mixed OO style, where only
 the core functionality is OO, while other functions explicitely pass
 the main object and can be stripped by the linker (avoiding bloat).

I don't see what you mean by passing the main object...
 [...] It doesn't make sense to add functions to libraries
 (to classes) when they increase the footprint of applications using the
 libraries. D has a way around this, but no established style to make
 good use of it. This hasn't been discussed.

Either I am not understanding (which is most probable) or that sounds like the need for a smart linker ( la Borland), which does not include functions in the executable if they are not called at all.
 Even the current Phobos library seems already a rather inconsistent
 mix of styles. I also think that the duplication of C functions in
 D libraries is a bad habit. We don't live under the 6/8 char name
 restriction anymore and should use readable names consistently.

Right said! Since D assumes at least a 32-bit flat memory space and Unicode support, why sticking with function declarations written in 1979, even if stdio.h was a blessing at the time?
 A way to do this would be introduce a common vocabulary of names
 with a defined meaning, so that a user/programmer can rely upon
 that any image function will have "Image" (and not "Picture",
 "Pict" or "Img") in its name. A while ago I did quite an amount
 of work about this type of consistent vocabularies. Typically its hard
 to get people to give up their "freedom" to name functions the way
 they like - but its the only way to get consistency into large APIs.

This sounds a little risky, but after all, that's what Sun did with Java, and M$ with .NET, just brought at a slightly higher level. And D *is* about bringing things at the next level, isn't it?
 The production of good apps (killer apps) will also work better when the
 developments can be coordinated to build the apps and the core library
 at the same time, avoiding redundant development work. This would need
 a repository where developers can directly contribute without creating
 unstable systems. This would need some kind of automated build and test
 system. But I've no idea how this could be accomplished.

I guess there's no way, for free at least... But having Phobos on a CVS (say on Sourceforge for instance) could be a good start, as long as Walter agrees. And while I'm on the subject: Phobos is a cool codename for the library, but maybe something like SDL (for "Standard D library") or the like, although all but original, could sound more convincing to people considering D for professional use. Needless to say, either Walter himself or someone who can be trusted to follow his guidelines must be in charge of CVS maintenance. As for myself, I'm willing to contribute, so expect to read more from me soon... Bye Ric
Jul 30 2003
prev sibling next sibling parent reply "J. Daniel Smith" <J_Daniel_Smith HoTMaiL.com> writes:
I think one of the reasons for C++'s popularity is that was easy to get
there from C.  The first step was to just compile all of your existing C
code with the C++ compiler, almost everything worked as-is and the needed
changes were minimal.  With just a little bit of effort, you could write
code that could be compiled with both the C and C++ compilers (this is still
somewhat true today, although things like the STL and C99 complicate
things).

As can be seen from Java and C#, it takes a tremendous amount of
time/effort/$$$ to birth a new language with everything that is required for
modern development (IDE, libraries, etc.).  D is probably always going to
have a hard time keeping up with the likes of Sun and Microsoft.

Something that might work with D - although it would require somewhat
substantial changes at this point - is to make D compatible with a "nice"
subset of C++.  This would allow D to easily leverage much of what is
available for C++; D-specific code could be inside of #ifdef's so that they
are only visible to the D compiler.

The D language offers a lot of advantages over C/C++/Java/C#; but I don't
think that by itself is enough to really make D popular.

   Dan

"Helmut Leitner" <leitner hls.via.at> wrote in message
news:3F279BAE.41C709AD hls.via.at...
 A few general thoughts about the current situation.

 Walter and Burton do an admirable job to push D forward. But to help
 them we (all others) have to find ways to contribute code and collaborate
 more effectively.

 To use D it's nice to have this tight C connection, but in the long
 run it will be an hindrance to make C popular. You can't write a nice
 and easy tutorial if you have to fall back to printf or scanf. So there
 should a line of thought that targets the non-C-D-beginner. In the end
 there must be something like (pseudocode):
    Print("Enter Date: ");
    Input(date);
    Push(DataArray,date);
    Print("Today: ",date);
 Only easy things become popular.

 The same is true for the stdlib. D needs the gui (dig), ide, print,
 image, scan, cgi, database and a miriad of other modules. But it won't
 help much if this functionality is distributed among many libraries
 and written in many different styles. We should find a way to establish
 a D library style, that's powerful and unbloated. It doesn't make sense
 to go the Java and C# way to just put anything in that's thinkable.
 (I specially remember the Java class to read numbered lines from a stream)
 We don't have Sun or Microsoft resources to go this "brute force" way.
 (And I don't think its programmer-friendly anyway)

 It seems that D would lend itself well to a mixed OO style, where only
 the core functionality is OO, while other functions explicitely pass
 the main object and can be stripped by the linker (avoiding bloat).
 For example, if you do user interfaces and report generations you handle
 all types of rectangular areas (frames) and dependencies. I think my
 C RECT module contains about 80 functions to split, join, change and
 position rectangles. It doesn't make sense to add functions to libraries
 (to classes) when they increase the footprint of applications using the
 libraries. D has a way around this, but no established style to make
 good use of it. This hasn't been discussed.

 Even the current Phobos library seems already a rather inconsistent
 mix of styles. I also think that the duplication of C functions in
 D libraries is a bad habit. We don't live under the 6/8 char name
 restriction anymore and should use readable names consistently.
 A way to do this would be introduce a common vocabulary of names
 with a defined meaning, so that a user/programmer can rely upon
 that any image function will have "Image" (and not "Picture",
 "Pict" or "Img") in its name. A while ago I did quite an amount
 of work about this type of consistent vocabularies. Typically its hard
 to get people to give up their "freedom" to name functions the way
 they like - but its the only way to get consistency into large APIs.

 The production of good apps (killer apps) will also work better when the
 developments can be coordinated to build the apps and the core library
 at the same time, avoiding redundant development work. This would need
 a repository where developers can directly contribute without creating
 unstable systems. This would need some kind of automated build and test
 system. But I've no idea how this could be accomplished.

 -- 
 Helmut Leitner    leitner hls.via.at
 Graz, Austria   www.hls-software.com

Jul 30 2003
parent reply "Riccardo De Agostini" <riccardo.de.agostini email.it> writes:
"J. Daniel Smith" <J_Daniel_Smith HoTMaiL.com> ha scritto nel messaggio
news:bg8pk6$1ina$1 digitaldaemon.com...

 I think one of the reasons for C++'s popularity is that was easy to get
 there from C.  The first step was to just compile all of your existing C
 code with the C++ compiler, almost everything worked as-is and the needed
 changes were minimal.

(C++'s main advantage over C) was far less popular than today; programmers had to gradually get used to C++ because it required them (us) to do things in a way they were not used to and, at first sight, required more typing and more complicated code (until people got used to OO *analysis*, that is). D, on the other hand, does not introduce dramatically new programming concepts and requires the programmer to type *less*. As long as the language does not get cluttered by strange symbols (see the discussion about string literals), I can't see a reason why a C++ programmer wouldn't want to switch to D, at least not a single reason regarding the language itself: the fact that perhaps I'll have to fight with my boss to use a non-M$ language, although bearing a practical importance, is not pertinent here.
 Something that might work with D - although it would require somewhat
 substantial changes at this point - is to make D compatible with a "nice"
 subset of C++.  This would allow D to easily leverage much of what is
 available for C++; D-specific code could be inside of #ifdef's so that

 are only visible to the D compiler.

macros. I like C-style macros, but only when I code in C, because they can help me write better and more understandable code, and even if they can make me write spaghetti code just as easily, in C there are no serious alternatives at times. Delphi, whose OO features resemble D in many ways, does not have a preprocessor, nor did I ever feel a need for it, except in one case where, thinking better, what I really needed was not a preprocessor, but templates (which D has). My personal vote goes against the preprocessor.
 The D language offers a lot of advantages over C/C++/Java/C#; but I don't
 think that by itself is enough to really make D popular.

Ric
Jul 31 2003
next sibling parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
 You're right, but I think times have changed enough. When C++ was born,

 (C++'s main advantage over C)

It never ceases to amaze me that people think C++ is an object-oriented language. It is not. It is a language that supports object-oriented programming (whatever that means) if that's what you choose to code. C++'s biggest advantage(s) over C are RAII and templates. Inheritance, and all the other OO gunk, is just a nice extra.
 I agree: it needs the best standard library ever seen. So let's make it!

Agreed with this. However, as I said in another thread, it needs to be orthogonal, efficient (in size and speed), and well thought-out/tested. Oh, and it needs to support equally those who program in "a better C", or who like OOP, or who like generics.
Jul 31 2003
parent reply "Riccardo De Agostini" <riccardo.de.agostini email.it> writes:
"Matthew Wilson" <matthew stlsoft.org> ha scritto nel messaggio
news:bgaguk$9ta$1 digitaldaemon.com...
 It never ceases to amaze me that people think C++ is an object-oriented
 language. It is not. It is a language that supports object-oriented
 programming (whatever that means) if that's what you choose to code.

 C++'s biggest advantage(s) over C are RAII and templates. Inheritance, and
 all the other OO gunk, is just a nice extra.

they held the key to programmer's heaven, and that key was OOP, at least according to marketing people. As to templates, C++ had been out for quite a while when they were introduced. So I agree with you, but they weren't part of the initial "big promise".
 Agreed with this. However, as I said in another thread, it needs to be
 orthogonal, efficient (in size and speed), and well thought-out/tested.

 and it needs to support equally those who program in "a better C", or who
 like OOP, or who like generics.

opinion, anyway. Ric
Jul 31 2003
parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
 Agreed with this. However, as I said in another thread, it needs to be
 orthogonal, efficient (in size and speed), and well thought-out/tested.

 and it needs to support equally those who program in "a better C", or


 like OOP, or who like generics.

opinion, anyway.

Am intrigued by what you mean here. Do you mean one or the other? For my part, I think the iostreams stink, but not because they attempt to provide a type-sensitive approach to streaming, rather just because it's done really badly. I would think we should support both stdio (probably just leave it as the C-interface, though that's not to say that people will not come up with worthy enhancements that do not take it away from the "raw" C model), and also a decent DStreams (have I just invented a new name?), that does all the things that the iostreams should have done well, and a lot more besides, while being small and quick. (Needless to say, the iostreams SUCK HARD when it comes to speed.) The DStreams would be a combination of template and non-template components that would provide a near maximal blend of speed, type-safety and ease-of-use, not to mention a decent exceptional model, and handling byte-order as a matter of course. If I was lucky enough to get voted onto the DLG panel, I would take a very keen interest in assisting with this very subject. (And if no-one starts any serious work on it within the next 2-3 months - by which time I may be free of book writing duties for a while - I will probably have a go at it myself. Time, as always, being the limiting factor. Russ Lewis and Jon Allen had a brief chat about this in March, but I've not heard anyone mention it since.) Matthew P.S. Ricardo, can you leave a blank line before your answers, when they're embedded, as it makes them hard to spot? :)
Jul 31 2003
parent reply "Riccardo De Agostini" <riccardo.de.agostini email.it> writes:
"Matthew Wilson" <matthew stlsoft.org> ha scritto nel messaggio
news:bgajqq$cd6$1 digitaldaemon.com...
 Am intrigued by what you mean here. Do you mean one or the other?

The point here was not having *two* I/O libraries. My personal preference goes to neither one: I find stdio to be nearly Louis XVI style and agree with every word you say about iostreams. I agree completely with your vision about the library, just I don't see the need for keeping stdio. I'd add that it is important to keep simple things simple: even Java's system.out.println looks too verbose in a "Hello world" example IMHO, fancy when you have to write hundreds of such calls in an app. I'd suggest stdin and stdout (maybe StdIn, StdOut and of course StdErr, or better DebugOut) as names for global classes, since StdOut.Write(<whatever>) looks "procedural" enough as to not scare C programmers so much as cout << <what> << <ever> can do. As to the DStreams name: looks sexy, but just Streams is perhaps more "natural". Since streams are to be part of D's standard library (at least that's what I infer from discussions on the NG) that would mean Dstreams, DContainers, DLists, DSockets, etc. for consistency. Now try to figure if everything in the STL was prefixed CPP... I'd also avoid DIO as a name for the I/O library, since it means "God" in Italian, so it makes for weird word tricks in sources. Being concerned about Microsoft and Sun makes sense, but when you add the Vatican it becomes overwhelming! :-) Ric
Jul 31 2003
parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
"Riccardo De Agostini" <riccardo.de.agostini email.it> wrote in message
news:bgamt3$f11$1 digitaldaemon.com...
 "Matthew Wilson" <matthew stlsoft.org> ha scritto nel messaggio
 news:bgajqq$cd6$1 digitaldaemon.com...
 Am intrigued by what you mean here. Do you mean one or the other?

The point here was not having *two* I/O libraries. My personal preference goes to neither one: I find stdio to be nearly Louis XVI style and agree with every word you say about iostreams.

Cool. ;)
 I agree completely with your vision about the library, just I don't see

 need for keeping stdio. I'd add that it is important to keep simple things
 simple: even Java's system.out.println looks too verbose in a "Hello

 example IMHO, fancy when you have to write hundreds of such calls in an

 I'd suggest stdin and stdout (maybe StdIn, StdOut and of course StdErr, or
 better DebugOut) as names for global classes, since

 looks "procedural" enough as to not scare C programmers so much as cout <<
 <what> << <ever> can do.

Makes sense. I just don't see us jettisoning stdio. That's not to say it will be promoted as the best way to do things, but really it cannot be removed, since we're always going to have the facility for calling C functions (with good reason).
 As to the DStreams name: looks sexy, but just Streams is perhaps more
 "natural". Since streams are to be part of D's standard library (at least
 that's what I infer from discussions on the NG) that would mean Dstreams,
 DContainers, DLists, DSockets, etc. for consistency. Now try to figure if
 everything in the STL was prefixed CPP...

I just thought it up on the spot. There'd be no reason to want to use that actual name in the code. It was more a working title.
 I'd also avoid DIO as a name for the I/O library, since it means "God" in
 Italian, so it makes for weird word tricks in sources. Being concerned

 Microsoft and Sun makes sense, but when you add the Vatican it becomes
 overwhelming! :-)

3 gods! Too many to contemplate. And only two of them real ...
Jul 31 2003
parent "Riccardo De Agostini" <riccardo.de.agostini email.it> writes:
"Matthew Wilson" <matthew stlsoft.org> ha scritto nel messaggio
news:bgao81$g3e$1 digitaldaemon.com...
 Makes sense. I just don't see us jettisoning stdio. That's not to say it
 will be promoted as the best way to do things, but really it cannot be
 removed, since we're always going to have the facility for calling C
 functions (with good reason).

With as many reasons as there are good, off-the-shelf (or off-the-CVS) third-party libraries with a C interface. If you tell me that D lets me use a $200 C library I bought six months ago and use every day, that's great! What? It also interfaces with third-party DLLs? A blessing! Can I also use WATT-32 (if just DMD compiled for DOS-32 too...)? Cool as dry ice!! Then you add "...and it has fopen and printf...". So what?! :-) It won't compile my C code as-is anyway (nor do I want it to do it) so let me see if it comes with something smarter than stdio... I understand that throwing the C RTL out of the D window completely is not very practical... I see two appealing possibilities: 1) Keeping the interface modules to the C RTL, but not as part of the core library, so as to make it clear that D can do the same things in a "native" way and, needless to say, better :-) 2) Create "interface" modules (not part of the core library, either) which implement, for instance, stdio functions with calls to the Streams library. More work involved, of course, but this would let us eliminate the use of pointers (especially char *) in library calls because, for instance, strrchr could take a char[] as parameter. Besides, the compiler would very probably make most of the calls inline, thus eliminating the overhead. With special regard to stdio, I confess that the idea of potentially having a Streams library *and* stdio linked together in the same app makes me feel uncomfortable.
 3 gods! Too many to contemplate. And only two of them real ...

Ric
Jul 31 2003
prev sibling parent "J. Daniel Smith" <J_Daniel_Smith HoTMaiL.com> writes:
The reason a C++ programmer won't switch to D is that in the real world
there is far too much "legacy" C++ code that you have to work with or
leverage.  Most people won't have the luxury of doing *everything* in D, and
providing D versions of IDEs, libraries, etc. is going to take a LONG time.
Having its roots in "systems programming", D's interface to legacy code is
through C, not C++: a C++ class can not be used directly (code compatible)
or indirectly (link compatible) by D.

I wasn't thinking of adding the whole C pre-processor to D, rather something
more along of the lines of C#'s very primitive "pre-processor" - enough to
let you #ifdef code.  The idea being that you could write this D dialect of
C++ to use with your C++ compiler, while #ifdef'ing out the D-specific
things that only the D compiler recognizes.

My whole point is that trying to duplicate everything C++/Java/C#/.NET has
in D is a herculean effort; thus my thoughts about changing D so that is
could easily leverage much of C++ similar to C++ using C.

   Dan

"Riccardo De Agostini" <riccardo.de.agostini email.it> wrote in message
news:bgaffd$8jt$1 digitaldaemon.com...
 "J. Daniel Smith" <J_Daniel_Smith HoTMaiL.com> ha scritto nel messaggio
 news:bg8pk6$1ina$1 digitaldaemon.com...

 I think one of the reasons for C++'s popularity is that was easy to get
 there from C.  The first step was to just compile all of your existing C
 code with the C++ compiler, almost everything worked as-is and the


 changes were minimal.


 (C++'s main advantage over C) was far less popular than today; programmers
 had to gradually get used to C++ because it required them (us) to do

 in a way they were not used to and, at first sight, required more typing

 more complicated code (until people got used to OO *analysis*, that is).

 on the other hand, does not introduce dramatically new programming

 and requires the programmer to type *less*. As long as the language does

 get cluttered by strange symbols (see the discussion about string

 I can't see a reason why a C++ programmer wouldn't want to switch to D, at
 least not a single reason regarding the language itself: the fact that
 perhaps I'll have to fight with my boss to use a non-M$ language, although
 bearing a practical importance, is not pertinent here.

 Something that might work with D - although it would require somewhat
 substantial changes at this point - is to make D compatible with a


 subset of C++.  This would allow D to easily leverage much of what is
 available for C++; D-specific code could be inside of #ifdef's so that

 are only visible to the D compiler.

macros. I like C-style macros, but only when I code in C, because they can help me write better and more understandable code, and even if they can

 me write spaghetti code just as easily, in C there are no serious
 alternatives at times. Delphi, whose OO features resemble D in many ways,
 does not have a preprocessor, nor did I ever feel a need for it, except in
 one case where, thinking better, what I really needed was not a
 preprocessor, but templates (which D has).
 My personal vote goes against the preprocessor.

 The D language offers a lot of advantages over C/C++/Java/C#; but I


 think that by itself is enough to really make D popular.


 Ric

Jul 31 2003
prev sibling next sibling parent "Walter" <walter digitalmars.com> writes:
You have some great points.

What we should do is look at other successful grass-roots language system,
like Perl and Python, and emulate what works for a collaborative system.
Jul 30 2003
prev sibling next sibling parent reply "Walter" <walter digitalmars.com> writes:
"Helmut Leitner" <leitner hls.via.at> wrote in message
news:3F279BAE.41C709AD hls.via.at...
 To use D it's nice to have this tight C connection, but in the long
 run it will be an hindrance to make C popular. You can't write a nice
 and easy tutorial if you have to fall back to printf or scanf. So there
 should a line of thought that targets the non-C-D-beginner. In the end
 there must be something like (pseudocode):
    Print("Enter Date: ");
    Input(date);
    Push(DataArray,date);
    Print("Today: ",date);
 Only easy things become popular.

Right up to a point. Notice that C++, Python, Java, Eiffel, C#, etc., etc., etc., all have some level of C compatibility. D has a tighter connection than all but C++, even if the only reason is that the operating system API calls are designed to work directly with C. D must have a tight C connection to succeed, so it can link with existing C code.
 The same is true for the stdlib. D needs the gui (dig), ide, print,
 image, scan, cgi, database and a miriad of other modules. But it won't
 help much if this functionality is distributed among many libraries
 and written in many different styles. We should find a way to establish
 a D library style, that's powerful and unbloated. It doesn't make sense
 to go the Java and C# way to just put anything in that's thinkable.
 (I specially remember the Java class to read numbered lines from a stream)
 We don't have Sun or Microsoft resources to go this "brute force" way.
 (And I don't think its programmer-friendly anyway)

I've started on a D style guide in the documentation, comments are welcome.
 Even the current Phobos library seems already a rather inconsistent
 mix of styles.

That's my fault. Some bits were contributed by others, and some bits are me casting around for what feels right.
 I also think that the duplication of C functions in
 D libraries is a bad habit. We don't live under the 6/8 char name
 restriction anymore and should use readable names consistently.

I partially disagree, for the reason that many C functions are so second nature. Yet many need to be re-engineered to take advantage of overloading, and to switch to the exception model of error handling rather than errno. Each needs to be evaluated on a case by case basis. I eventually want to duplicate enough of the C RTL's functionality that one will not need to link to the C RTL for most purposes.
 A way to do this would be introduce a common vocabulary of names
 with a defined meaning, so that a user/programmer can rely upon
 that any image function will have "Image" (and not "Picture",
 "Pict" or "Img") in its name. A while ago I did quite an amount
 of work about this type of consistent vocabularies. Typically its hard
 to get people to give up their "freedom" to name functions the way
 they like - but its the only way to get consistency into large APIs.

I agree.
Jul 30 2003
parent reply "Riccardo De Agostini" <riccardo.de.agostini email.it> writes:
"Walter" <walter digitalmars.com> ha scritto nel messaggio
news:bg965n$20lp$1 digitaldaemon.com...
 I partially disagree, for the reason that many C functions are so second
 nature. Yet many need to be re-engineered to take advantage of

 and to switch to the exception model of error handling rather than errno.
 Each needs to be evaluated on a case by case basis. I eventually want to
 duplicate enough of the C RTL's functionality that one will not need to

 to the C RTL for most purposes.

approach at creating a standard library for D, IMHO... Besides, I don't regard things like fputs, putc, fscputksfv :-) as "practical" programming. Most C programmers I've seen have a tendency to be influenced by the RTL style, yielding things like (as saw by me in production code!) three global variables named RtlSrvMnb, RtlMnbSrv and SrvRtlMnb, and, in general, identifiers seemingly generated by a kitten playing on a keyboard. As for second nature, one who has been coding in C since 1980 will hardly switch... OTOH, there are lots of newbies out there, and they are the future. Let's give them (and us) a really practical RTL. I think D deserves it. Ric
Jul 31 2003
parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
 As for second nature, one who has been coding in C since 1980 will hardly
 switch...

That's utter nonsense. On what do you base this? There are old farts who refuse to learn anything newer than the crufty old stuff they learned in university in the 1960s,. and there are ignorant young fools who refuse to learn anything newer or older than that Java/VB they learned in university in the late 1990s. The defining characteristics of these types of people is that they are crap, nothing to do with their age. Furthermore, I haven't spotted any people from this "type" on the D newsgroup, which seems to attract those who are both skilled and open-minded.
 OTOH, there are lots of newbies out there, and they are the
 future.

They'll only be the future if they learn from people with more experience! As someone who is (in age at least - 35) halfway between the two groups you talk about, I find it incredible to think of your characterisation of either camp. As I get older and more experienced, I learn that I know less than I think I do (something which newbies fail to do to a man) and also become better able to learn new languages and to appreciate the old ones in different ways. So basically I think your two characterisations are wrong and/or fatuous. What we need to do with D is achieve: - efficient execution - efficient coding - and this includes the major component of software engineering (which is never mentioned on this ng!!): maintainance. - lends itself to good design - be grounded in reality. This means being C compatible. - and lot's more besides. Walter is trying to create a language that will be better than C++ (and Java, .NET, etc. etc.). Since all those existing successful languages have got more flaws than you can shake a stick at, perhaps there is some deeper meaning on the likelihood of success based on pragmatism vs idealism. Someone with better memory than I posted something really interesting on how imperfect languages win out over perfect ones every time. If they can be so good as to do so again, I think we should all (re-)read and digest. I recall it was very compelling Matthew
Jul 31 2003
next sibling parent reply "Riccardo De Agostini" <riccardo.de.agostini email.it> writes:
"Matthew Wilson" <matthew stlsoft.org> ha scritto nel messaggio
news:bgahju$adu$1 digitaldaemon.com...
 As for second nature, one who has been coding in C since 1980 will


 switch...

That's utter nonsense. On what do you base this? [interesting arguments follow, not quoted for brevity]

I admit my characterisation was over-simplified and thank you for pointing it out. I, too, am in the middle between the two groups (33, and if I was not willing to learn a new language, what should I be supposed to do here? :-) ). Surely all people in this NG are both skilled and open-minded, but obviously I was not talking about them. Maybe I was talking about myself, in a way: I didn't recognize C++ as a way to write better code for a long time, because I could simply write more-or-less C and it would compile it. On the contrary, when I had to face Delphi I was compelled to really learn it (I'll never thank my former boss enough for that). When I finally discovered that C++ has features I had learnt to appreciate in Delphi I was nearly shocked, _then_ I discovered templates and said WOW! Now a C compiler has no chance to compile more than 0.1% of my code :-) Maybe if I had _had_ to learn something in order to use C++ the first time, I could have written better code from the start. D is not nearly so different from C++ as Delphi is, and has no real drawback (Delphi has some, indeed), so I don't think an average, medium-brain-sized newbie, or senior for that matter, needs exactly the same syntax as C++ nor a preprocessor to start using D profitably, while he/she could even benefit from having to recode that 3-year-old module... While I'm on the subject, I think that releasing all the RTL source code would be a great help for people approaching D after having learnt programming with C++ (or C, or Delphi, or <insert language here>). I hope not to be too boring... :-) Ric
Jul 31 2003
parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
"Riccardo De Agostini" <riccardo.de.agostini email.it> wrote in message
news:bgak8m$cna$1 digitaldaemon.com...
 "Matthew Wilson" <matthew stlsoft.org> ha scritto nel messaggio
 news:bgahju$adu$1 digitaldaemon.com...
 As for second nature, one who has been coding in C since 1980 will


 switch...

That's utter nonsense. On what do you base this? [interesting arguments follow, not quoted for brevity]

I admit my characterisation was over-simplified and thank you for pointing it out. I, too, am in the middle between the two groups (33, and if I was not willing to learn a new language, what should I be supposed to do here? :-) ).

Indeed.
 Surely all people in this NG are both skilled and open-minded, but

 I was not talking about them.

That's fair. But I would think that the D ng people will be the first disciples (to continue the disturbing religious metaphor from the other thread!), and given the quite large spectrum of talent and experience in the ng, this will form a compelling case for D being taken seriously on a broader scale.
 Maybe I was talking about myself, in a way: I didn't recognize C++ as a

 to write better code for a long time, because I could simply write
 more-or-less C and it would compile it. On the contrary, when I had to

 Delphi I was compelled to really learn it (I'll never thank my former boss
 enough for that). When I finally discovered that C++ has features I had
 learnt to appreciate in Delphi I was nearly shocked, _then_ I discovered
 templates and said WOW! Now a C compiler has no chance to compile more

 0.1% of my code :-)

I am no adherent to all things C++ - I'm currently writing a book on C++ whose theme is pointing out the flaws! - but I find most of the criticisms of people who do not have a considerable degree of expertise in it to be second-hand at best. There are many things wrong with C++, but it is still the best language out there for most tasks where efficiency, expressiveness and being within shouting distance of the architecture are necessary. Perhaps one of the problems is just how much one needs to learn in order to get that level of expertise. And the push towards template nervana is not helping matters. I do a *lot* of template stuff - despite attempts to unify and simplity (I'm the author of STLSoft, which ships with DMC++) - as well as writing about it, but when I look at some of the other template libraries out there my head hurts as much as the next man. (I have a hypothesis that there are just as many template cowboys now as there were inheritance cowboys a few years ago, they've just swapped working-set-size for number-of-people-I-can-confound-with-my-cleverness.) The language is getting better and more powerful, but there is a bigger wake of people left behind, who consequently move towards Java, .NET, Delphi, and similar middle-tier power languages. I hope and expect that D can fill the gap between these so-called middle-tier languages and the blue-skies that C++ is rushing towards, so that it provides accessibility and simplicity for the (sensible) majority, as well as providing powerful generics and even meta-programming capabilities for those who need to fly higher (for good or ill).
 Maybe if I had _had_ to learn something in order to use C++ the first

 I could have written better code from the start. D is not nearly so
 different from C++ as Delphi is, and has no real drawback (Delphi has

 indeed), so I don't think an average, medium-brain-sized newbie, or senior
 for that matter, needs exactly the same syntax as C++ nor a preprocessor

 start using D profitably, while he/she could even benefit from having to
 recode that 3-year-old module...

 While I'm on the subject, I think that releasing all the RTL source code
 would be a great help for people approaching D after having learnt
 programming with C++ (or C, or Delphi, or <insert language here>).

Agreed
 I hope not to be too boring... :-)

Quite the contrary
Jul 31 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bgaoqt$gj4$1 digitaldaemon.com...
 I am no adherent to all things C++ - I'm currently writing a book on C++
 whose theme is pointing out the flaws! - but I find most of the criticisms
 of people who do not have a considerable degree of expertise in it to be
 second-hand at best. There are many things wrong with C++, but it is still
 the best language out there for most tasks where efficiency,

 and being within shouting distance of the architecture are necessary.
 Perhaps one of the problems is just how much one needs to learn in order

 get that level of expertise. And the push towards template nervana is not
 helping matters. I do a *lot* of template stuff - despite attempts to

 and simplity (I'm the author of STLSoft, which ships with DMC++) - as well
 as writing about it, but when I look at some of the other template

 out there my head hurts as much as the next man. (I have a hypothesis that
 there are just as many template cowboys now as there were inheritance
 cowboys a few years ago, they've just swapped working-set-size for
 number-of-people-I-can-confound-with-my-cleverness.) The language is

 better and more powerful, but there is a bigger wake of people left

 who consequently move towards Java, .NET, Delphi, and similar middle-tier
 power languages.

I admit that C++ templates make my eyeballs hurt. The inventors of STL have discovered an important new way of programming, though, and some aspects of templates are pure genious. But C++ templates are so complicated that they leave most real world programmers behind including many expert coders who won't use them because they know that their successor will just throw their code away because they cannot follow it. There's got to be a better way. A lot of the interest in Java comes from people who reject the complexity of C++. It's too hard to learn, too hard to master, and too hard to debug. (Ever tried to figure out why a template isn't working?) While D does have templates, it incorporates into the core language many things that C++ templates try to address, such as superior string handling. I believe this will make these powerful features much more accessible, and will help people use them correctly and efficiently.
 I hope and expect that D can fill the gap between these so-called
 middle-tier languages and the blue-skies that C++ is rushing towards, so
 that it provides accessibility and simplicity for the (sensible) majority,
 as well as providing powerful generics and even meta-programming
 capabilities for those who need to fly higher (for good or ill).

Yes, exactly.
Aug 07 2003
next sibling parent "Mike Wynn" <mike.wynn l8night.co.uk> writes:
"Walter" <walter digitalmars.com> wrote in message
news:bgvad0$1qf2$1 digitaldaemon.com...
 A lot of the interest in Java comes from people who reject the complexity

 C++. It's too hard to learn, too hard to master, and too hard to debug.
 (Ever tried to figure out why a template isn't working?)

in some other app, rather than Java for bare metal programming) because you know (well believe) that a Java servlet/applet/app will not crash your main app (web server, pda, phone etc) if its been written badly, and it only gets the interface to the OS/app its embedded in that the VM vendor/device vendor supplies. with a dynamic compiler that can delete compiled code the memory foot print can be quite small too without much performance penalty. even in non embedded applications Java is a lot more robust than most compiled langs, you can create null pointer or array index exceptions if your code is incorrect, but you can't walk over your own stack frame (or a parent frame) something that in C, C++ is all to easy to do and D creates a few more fun ways to do it too (miss use of array slicing on a stack allocated array, misuse of address of an inner function to name the ones I've tried)
Aug 07 2003
prev sibling parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
"Walter" <walter digitalmars.com> wrote in message
news:bgvad0$1qf2$1 digitaldaemon.com...
 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bgaoqt$gj4$1 digitaldaemon.com...
 I am no adherent to all things C++ - I'm currently writing a book on C++
 whose theme is pointing out the flaws! - but I find most of the


 of people who do not have a considerable degree of expertise in it to be
 second-hand at best. There are many things wrong with C++, but it is


 the best language out there for most tasks where efficiency,

 and being within shouting distance of the architecture are necessary.
 Perhaps one of the problems is just how much one needs to learn in order

 get that level of expertise. And the push towards template nervana is


 helping matters. I do a *lot* of template stuff - despite attempts to

 and simplity (I'm the author of STLSoft, which ships with DMC++) - as


 as writing about it, but when I look at some of the other template

 out there my head hurts as much as the next man. (I have a hypothesis


 there are just as many template cowboys now as there were inheritance
 cowboys a few years ago, they've just swapped working-set-size for
 number-of-people-I-can-confound-with-my-cleverness.) The language is

 better and more powerful, but there is a bigger wake of people left

 who consequently move towards Java, .NET, Delphi, and similar


 power languages.

I admit that C++ templates make my eyeballs hurt. The inventors of STL

 discovered an important new way of programming, though, and some aspects

 templates are pure genious. But C++ templates are so complicated that they
 leave most real world programmers behind including many expert coders who
 won't use them because they know that their successor will just throw

 code away because they cannot follow it. There's got to be a better way.

Me too, and I'm a promulgator of it. (ftr, I think most people need a serious rethink in terms of just they format their templates. Clarity is so often overlooked ...) It's a bizarre position. I get STL as a concept, and well into implementing it, as you know, but I find other people's template, esp. STL-like, almost impossible to understand. Now I'm neither a genius nor a dummy, but I figure if I have a hard time with templates when I do reasonably complex things with them most days, then something's got to give. Having said that, the power is just a must-have, and this is why we won't be seeing anything replace C++ *and* STL for a very long time. Maybe D can be that thing eventually, I dunno, but if it is, it'd better have all the power that C++ + STL has, to even stand a chance.
 A lot of the interest in Java comes from people who reject the complexity

 C++. It's too hard to learn, too hard to master, and too hard to debug.
 (Ever tried to figure out why a template isn't working?)

Usually easy if it's runtime (and you have a decent debugger). _Much_ harder if compile-time.
 While D does have templates, it incorporates into the core language many
 things that C++ templates try to address, such as superior string

 I believe this will make these powerful features much more accessible, and
 will help people use them correctly and efficiently.

Maybe. I do hope so, but if they don't all work with and without a generics facility that is equal (or pretty close) to that of C++ + STL then it won't matter (to C++ people, anyway). Perhaps we can get this moving in the next month or two ...
 I hope and expect that D can fill the gap between these so-called
 middle-tier languages and the blue-skies that C++ is rushing towards, so
 that it provides accessibility and simplicity for the (sensible)


 as well as providing powerful generics and even meta-programming
 capabilities for those who need to fly higher (for good or ill).

Yes, exactly.

I take it you're on board then. If/when a group of us get the time and energy to really do a DTL, I take it we can count on your facilitating our demands with frequent, major DMD re-writes? ;)
Aug 07 2003
parent "Walter" <walter digitalmars.com> writes:
"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bgvgkc$1vnj$1 digitaldaemon.com...
 I take it you're on board then. If/when a group of us get the time and
 energy to really do a DTL, I take it we can count on your facilitating our
 demands with frequent, major DMD re-writes? ;)

Yes, I'm up for working on the syntax of D templates to make a DTL work.
Aug 10 2003
prev sibling parent reply Bill Cox <bill viasic.com> writes:
Hi.

Matthew Wilson wrote:

...

OTOH, there are lots of newbies out there, and they are the
future.

They'll only be the future if they learn from people with more experience!

I think there is some merit in trying to reach out to the university students somehow. When they graduate, whatever language they've been told is the best will be forced into use in industry. It happens all the time. There's an unfortunate process at work, that I see going like this: -- Someone invents a really very difficult programming language to use or understand, and gets some good hype with some new buzz words, and perhaps a few real inovations. -- The smartest university students want to learn it, partly because only smart guys can, and they want to prove themselves. They dive in, master it, and then want to use it. -- Industry hires these smartest guys, and get pushed into using the new difficult language on new projects. -- The average programmers get hired to maintain the code the smart guys wrote, and can't understand it or work with it. They totally mess it up. For C, the draw was difficult pointers and type declarations. Do you remember "The C Puzzle Book"? All the smart students studied it. How about the "Obfuscated C Code Contest"? C++ totally outclassed C in complexity, and has some concepts that most programmers will never understand or use. Smart students were attracted to it like moths to a flame. C++ was a language so complex, they could gain understanding of it for months (if they really are smart), or years (if they're just above average). It gave them a way to express code that clearly demonstrated their intellect even if the problem was something simple, like "Hello, world". I think one problem for D with the university crowd is that it's a bit to simple. Design by contract, and unit test are great buzz words, but a bit too easy to use and understand. Also, QA features are for the masses, not guys who preffer *p->q++**++ to a subroutine call like "moveToNextWord". If it's not dangerous, and difficult, it will have a hard time being hip with the smart students. Bill P.S. I seem to keep posting problems without posting solutions, so here's some suggestions for how to make D seem more difficult. Perhaps someone could write "The D Puzzle Book". Conversions of D strings to C strings would be a good one to start with :-). How about the 9 different ways to delcare "bool", and the tricky conversion bugs that result? Include hard to understand features to help smart guys differentiate themselves: -- Multimethods -- Virtual Classes -- Template frameworks -- Functional programming -- Sather's looping constructs -- Compile time mirror classes In fact, if we don't include these kinds of things, someone is sure to come out with D++ shortly :-). Smart guys just can't help themselves.
Jul 31 2003
next sibling parent reply "Riccardo De Agostini" <riccardo.de.agostini email.it> writes:
"Bill Cox" <bill viasic.com> ha scritto nel messaggio
news:3F291E4B.2020208 viasic.com...
 There's an unfortunate process at work, that I see going like this:
 [...]

ROTFL! Ric P.S.: I agree with the serious parts of your post. I just hope your proposal about making D more complicated is not among them.
Jul 31 2003
parent Bill Cox <bill viasic.com> writes:
Riccardo De Agostini wrote:
 "Bill Cox" <bill viasic.com> ha scritto nel messaggio
 news:3F291E4B.2020208 viasic.com...
 
There's an unfortunate process at work, that I see going like this:
[...]

ROTFL! Ric P.S.: I agree with the serious parts of your post. I just hope your proposal about making D more complicated is not among them.

No, I wasn't serious. I think the recent posts on this group are right-on. D may become popular if we can paste together good libs, IDE support, and so on. I just wish there were more avenues that could be taken. Bill
Aug 01 2003
prev sibling parent "Walter" <walter digitalmars.com> writes:
"Bill Cox" <bill viasic.com> wrote in message
news:3F291E4B.2020208 viasic.com...
 How about the "Obfuscated C Code Contest"?

LOL. Did you know that I won that contest years back? I can write horrible code with the worst of them <g>.
 In fact, if we don't include these kinds of things, someone is sure to
 come out with D++ shortly :-).  Smart guys just can't help themselves.

We could start with the Obfuscated D Code Contest!
Aug 07 2003
prev sibling parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
Maybe we're trying to byte off more than we can chew.

For my part, I am much more interested in writing libraries than in writing
applications, but for others it is the other way round.

* We need good libraries to support the language development, a consistent
and efficient implementation of applications, etc. etc. (All the reasons one
needs libraries, basically).

* We need (at least one) good applications to promote the library. We can
get it noticed by writing articles in the mainstream press (btw, it looks
like two of mine are coming out next month in a WDN online supplement), and
such, but until there is a significant piece of "wow"-ing software out
there, people are going to be "so-what"-ing it.


Unfortunately, I don't believe that an autocratic/top-down approach is going
to work. I think D needs a libraries group (DLG), composed of interested and
experienced volunteers, ratified by big W, of course.

Library submissions would be made, or requested, from work carried out in
*real* projects. These real projects don't have to be massive; oftentimes a
simple utility can tease out a neat little library . It is almost always the
case that good software is written twice, so let (in fact encourage) people
do their own thing with their own applications/libraries. Each person will
learn more about D in the process, and therefore be able to offer reasoned
debate during the library ratification process.

I think two types of libraries should be considered:

 1. SDL / Phobos

The libraries group would ensure that Phobos would be as small as is
reasonable and no smaller. In other words, all essential features go in
here, but nothing domain/application specific

These libs would be binary, and shipped with the compiler, and probably
automatically linked in (though with an optional -nosdl flag to not do so).
Whether they have source provided or not is, I guess, up to Walter at this
time.

 2. Domain/Application/Technology specific libraries

For my part I do not care whether these are also "owned" by D or whether
they exist as 3rd-party, but DLG-sanctioned, libraries. For example, I did
some D performance_counter libs (http://synsoft.org/d.html) for some
articles I wrote (the ones coming out in Aug, hopefully) which could either
exist as a discrete entity with the DLG mark of approval, or could be rolled
into a DMD-owned thing. (ftr, I've not got round to open-sourcing them, but
plan to as soon as I get round to it.)

hence:

 2a. DMD supplemental libraries - owned by DMD, shipped with the compiler
 2b. 3rd party DLG-ratified libraries - owned by whomever, probably
open-source, may/may not be shipped with the compiler


The aims/responsiblities of the DLG would include:

 - sniff out good potential libs to give the DLG treatment and approval
 - respond to submissions for potential libs
 - ensure that principles of efficiency, orthogonality, robustness, etc.,
are adhered to, and be *helpful* to submittors on how to rectify any such
deficits
 - ensure that libs come along with documentation, test cases, samples, etc.
 - maintain a sense of proportion about their own importance (lord knows
there are enough prima-donnas in other languages standards processes!)
 - etc.


So who would serve on the DLG?

- people expert in D - Burton, Sean, etc. etc.
- representatives of DM - I think that means Walter!!
- people expert in writing libs
- people who can manage these kind of things
- people with enough time - that probably eliminates everyone! :(


How would DLG work?

I have no fixed idea. However, I would think there would be a centralised
(email-based?) notification system of proposals, regular distribution of the
latest candidates and their review progress. Each library submission would
have to fulfil initial criteria (i.e. include minimum amount of docs, test
cases, etc.), and go under the nose of, say, three DGL members.

The downside is that all of this sounds like it might take a lot of effort.
I guess we'd just have to see how it goes.


All of this would be meaningful given sufficient stability and maturity in D
and DMD. I've not got the feeling yet that that is the case (although I'm
happy to be told otherwise). So it may be too soon for DLG, or it may the
right time.


I've just thrown all this out before breakfast, so may have overlooked some
obvious reasons against. Shoot away.

What do you all think?

Matthew
Jul 30 2003
next sibling parent "Riccardo De Agostini" <riccardo.de.agostini email.it> writes:
"Matthew Wilson" <matthew stlsoft.org> ha scritto nel messaggio
news:bg9lde$2gct$1 digitaldaemon.com...

 Unfortunately, I don't believe that an autocratic/top-down approach is

 to work. I think D needs a libraries group (DLG), composed of interested

 experienced volunteers, ratified by big W, of course.

 Library submissions would be made, or requested, from work carried out in
 *real* projects. These real projects don't have to be massive; oftentimes

 simple utility can tease out a neat little library .

than a comparable utility written in another language, say C++ for instance... D surely has the potential for this.
 I think two types of libraries should be considered:

  1. SDL / Phobos

 The libraries group would ensure that Phobos would be as small as is
 reasonable and no smaller. In other words, all essential features go in
 here, but nothing domain/application specific

 These libs would be binary, and shipped with the compiler, and probably
 automatically linked in (though with an optional -nosdl flag to not do

 Whether they have source provided or not is, I guess, up to Walter at this
 time.

  2. Domain/Application/Technology specific libraries

 For my part I do not care whether these are also "owned" by D or whether
 they exist as 3rd-party, but DLG-sanctioned, libraries. [...]

  2a. DMD supplemental libraries - owned by DMD, shipped with the compiler
  2b. 3rd party DLG-ratified libraries - owned by whomever, probably
 open-source, may/may not be shipped with the compiler

FWIW you have my vote!
 The aims/responsiblities of the DLG would include:

  - sniff out good potential libs to give the DLG treatment and approval
  - respond to submissions for potential libs
  - ensure that principles of efficiency, orthogonality, robustness, etc.,
 are adhered to, and be *helpful* to submittors on how to rectify any such
 deficits
  - ensure that libs come along with documentation, test cases, samples,

  - maintain a sense of proportion about their own importance (lord knows
 there are enough prima-donnas in other languages standards processes!)
  - etc.

Things begin to take shape... and it's a shape I personally like a lot.
 So who would serve on the DLG?
 [...]
 How would DLG work?
 [...]
 The downside is that all of this sounds like it might take a lot of

 I guess we'd just have to see how it goes.

 All of this would be meaningful given sufficient stability and maturity in

 and DMD. I've not got the feeling yet that that is the case (although I'm
 happy to be told otherwise). So it may be too soon for DLG, or it may the
 right time.

work is going to help the final rush towards DMD 1.0.
 I've just thrown all this out before breakfast, so may have overlooked

 obvious reasons against. Shoot away.

Ric
Jul 31 2003
prev sibling parent reply Burton Radons <loth users.sourceforge.net> writes:
Matthew Wilson wrote:
 The libraries group would ensure that Phobos would be as small as is
 reasonable and no smaller. In other words, all essential features go in
 here, but nothing domain/application specific

IMO Phobos should be cannibalised. The purpose of having a default install set is because dealing with the auto-installer is too difficult; so we should make the auto-installer easy to use and browse with. It should also be configurable, so that loading it with a default set of packages (dmd, dmc, a few libraries) should be easy. SDL bad. I don't like acronyms. They're all taken and they convey no information.
 These libs would be binary, and shipped with the compiler, and probably
 automatically linked in (though with an optional -nosdl flag to not do so).
 Whether they have source provided or not is, I guess, up to Walter at this
 time.

No automatic linking. The source defines the libraries it uses.
 The aims/responsiblities of the DLG would include:
 
  - sniff out good potential libs to give the DLG treatment and approval
  - respond to submissions for potential libs
  - ensure that principles of efficiency, orthogonality, robustness, etc.,
 are adhered to, and be *helpful* to submittors on how to rectify any such
 deficits
  - ensure that libs come along with documentation, test cases, samples, etc.
  - maintain a sense of proportion about their own importance (lord knows
 there are enough prima-donnas in other languages standards processes!)
  - etc.

Perhaps over time, but at this point the library group would be implementing the standard library itself.
 How would DLG work?
 
 I have no fixed idea. However, I would think there would be a centralised
 (email-based?) notification system of proposals, regular distribution of the
 latest candidates and their review progress. Each library submission would
 have to fulfil initial criteria (i.e. include minimum amount of docs, test
 cases, etc.), and go under the nose of, say, three DGL members.

I think it would be best to start with a mailing list and a CVS and expand according to what turns out to be necessary.
 All of this would be meaningful given sufficient stability and maturity in D
 and DMD. I've not got the feeling yet that that is the case (although I'm
 happy to be told otherwise). So it may be too soon for DLG, or it may the
 right time.

It's self-feeding. D can't be mature until it has a good library. Not having a good library decreases maturity over time due to reimplementations. I think I've implemented file stat and directory listing six times over the year; the first time was the most comprehensive, the rest I just wanted to get the task over with.
Aug 03 2003
next sibling parent reply "Les Baker" <lesbaker innovaREMOVETHIS.net> writes:
 SDL bad.  I don't like acronyms.  They're all taken and they convey no
 information.

FYI on a potential name collision too -- "SDL" is the acronym for Simple Directmedia Layer, a multimedia library for C. I kinda like "Phobos" anyhow; it's creative and is a nice allusion to the "Digital Mars" name.
Aug 03 2003
next sibling parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
This is all kind of missing the point. If I gave the impression that I
thought the particular, made-up-on-the-spot, acronyms, were important, or
even that giving the things discussed acronyms at all was important, let me
recant now.

What I was interested in learning was whether anybody (a) thought it
worthwhile trying to get some structure to the arbitrary individual efforts
going on atm, and (b) whether anyone would be prepared to invest of
themselves in making such a structure eventuate.

Matthew

"Les Baker" <lesbaker innovaREMOVETHIS.net> wrote in message
news:bgk875$e1r$1 digitaldaemon.com...
 SDL bad.  I don't like acronyms.  They're all taken and they convey no
 information.

FYI on a potential name collision too -- "SDL" is the acronym for Simple Directmedia Layer, a multimedia library for C. I kinda like "Phobos" anyhow; it's creative and is a nice allusion to the "Digital Mars" name.

Aug 03 2003
next sibling parent "Charles Sanders" <sanders-consulting comcast.net> writes:
Hehe, i like phobos too btw.

 (a) thought it
 worthwhile trying to get some structure to the arbitrary individual

 going on atm

Definetly! I think this is very important, and I think we should stop just talking about it and get started.
 (b) whether anyone would be prepared to invest of
 themselves in making such a structure eventuate.

I'll do what I can, though don't think Im completely qualified for the base library, I'm going to start work on binding libcurl (soon I swear!). Given the modest nature of the people on this list , I think we might have to vote people on, wether they like it or not! Charles "Matthew Wilson" <matthew stlsoft.org> wrote in message news:bgkd79$ii4$1 digitaldaemon.com...
 This is all kind of missing the point. If I gave the impression that I
 thought the particular, made-up-on-the-spot, acronyms, were important, or
 even that giving the things discussed acronyms at all was important, let

 recant now.

 What I was interested in learning was whether anybody (a) thought it
 worthwhile trying to get some structure to the arbitrary individual

 going on atm, and (b) whether anyone would be prepared to invest of
 themselves in making such a structure eventuate.

 Matthew

 "Les Baker" <lesbaker innovaREMOVETHIS.net> wrote in message
 news:bgk875$e1r$1 digitaldaemon.com...
 SDL bad.  I don't like acronyms.  They're all taken and they convey no
 information.

FYI on a potential name collision too -- "SDL" is the acronym for Simple Directmedia Layer, a multimedia library for C. I kinda like "Phobos" anyhow; it's creative and is a nice allusion to


 "Digital Mars" name.


Aug 03 2003
prev sibling parent reply "Riccardo De Agostini" <riccardo.de.agostini email.it> writes:
"Matthew Wilson" <matthew stlsoft.org> ha scritto nel messaggio
news:bgkd79$ii4$1 digitaldaemon.com...
 (a) thought it worthwhile trying to get some structure to the
 arbitrary individual efforts going on atm

Absolutely. Some people are already developing D libraries, naming them after the author (import net.BurtonRadons.*), which is correct; but "core" libraries such as file system access, etc. deserve something like "import std.files" if not even "import files". Besides, I think that having to type "import net.RiccardoDeAgostini.*" could discourage even myself from using my own libraries (as soon as I have some ready, that is).
 (b) whether anyone would be prepared to invest of
 themselves in making such a structure eventuate.

My objective is to replace C++ as the "standard" language at work, with something as comfortable as Delphi. D fits perfectly (also because of its first-sight resemblance with C, which is a strong psychological weapon because my boss has been programming in C for what seems to be ages). Would I invest some of my time in order to make my job easier and more fun? You bet!! Ric
Aug 04 2003
parent reply Helmut Leitner <leitner hls.via.at> writes:
Riccardo De Agostini wrote:
 
 "Matthew Wilson" <matthew stlsoft.org> ha scritto nel messaggio
 news:bgkd79$ii4$1 digitaldaemon.com...
 (a) thought it worthwhile trying to get some structure to the
 arbitrary individual efforts going on atm

Absolutely. Some people are already developing D libraries, naming them after the author (import net.BurtonRadons.*), which is correct; but "core" libraries such as file system access, etc. deserve something like "import std.files" if not even "import files".

Arrgh. "import files" will collide with any Sourcefile "files.d" that someone might use in his own projects. So don't even think about this. -- Helmut Leitner leitner hls.via.at Graz, Austria www.hls-software.com
Aug 04 2003
parent reply "Riccardo De Agostini" <riccardo.de.agostini email.it> writes:
"Helmut Leitner" <leitner hls.via.at> ha scritto nel messaggio
news:3F2E36BA.21A935A9 hls.via.at...
 Arrgh. "import files" will collide with any Sourcefile "files.d" that
 someone might use in his own projects. So don't even think about this.

As a matter of fact, I was not. :-) Just making an example. A rather bad example, as it turns out. Thinking better, the need to avoid name collisions could easily make the standard library end up with all module names starting with "__std__" or something equally useless and/or weird. So my preference goes, definitely, to a "std" folder and thus a "std." prefix in imports. Ric
Aug 04 2003
parent Helmut Leitner <helmut.leitner chello.at> writes:
Riccardo De Agostini wrote:
 
 "Helmut Leitner" <leitner hls.via.at> ha scritto nel messaggio
 news:3F2E36BA.21A935A9 hls.via.at...
 Arrgh. "import files" will collide with any Sourcefile "files.d" that
 someone might use in his own projects. So don't even think about this.

As a matter of fact, I was not. :-) Just making an example. A rather bad example, as it turns out. Thinking better, the need to avoid name collisions could easily make the standard library end up with all module names starting with "__std__" or something equally useless and/or weird. So my preference goes, definitely, to a "std" folder and thus a "std." prefix in imports.

I think there have been a number of discussions about this. As we have already c.stdio module names like d.files might also be nice and short. -- Helmut Leitner leitner hls.via.at Graz, Austria www.hls-software.com
Aug 04 2003
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Les Baker" <lesbaker innovaREMOVETHIS.net> wrote in message
news:bgk875$e1r$1 digitaldaemon.com...
 SDL bad.  I don't like acronyms.  They're all taken and they convey no
 information.

FYI on a potential name collision too -- "SDL" is the acronym for Simple Directmedia Layer, a multimedia library for C. I kinda like "Phobos" anyhow; it's creative and is a nice allusion to the "Digital Mars" name.

I'm sick of acronyms, too.
Aug 16 2003
parent Andrew Marlow <Andrew_member pathlink.com> writes:
In article <bhknmd$1nqb$4 digitaldaemon.com>, Walter says...
"Les Baker" <lesbaker innovaREMOVETHIS.net> wrote in message
news:bgk875$e1r$1 digitaldaemon.com...
 SDL bad.  I don't like acronyms.  They're all taken and they convey no
 information.

FYI on a potential name collision too -- "SDL" is the acronym for Simple Directmedia Layer, a multimedia library for C.


It also stands for System Design Language,a design notation still used in telecoms.
 I kinda like "Phobos" anyhow; it's creative and is a nice allusion to the
 "Digital Mars" name.


I don't. It ties the name to DigitalMars, rendering it forever niche. If D is going to get more widespread usage it has to have a life outside of DigitalMars. -Andrew Marlow
Aug 17 2003
prev sibling next sibling parent "Riccardo De Agostini" <riccardo.de.agostini email.it> writes:
"Burton Radons" <loth users.sourceforge.net> ha scritto nel messaggio
news:bgjeod$2nvl$1 digitaldaemon.com...
 IMO Phobos should be cannibalised.

Munch, munch, crunch, crunch... :-)
 No automatic linking.  The source defines the libraries it uses.

Agree 100%
 [...] at this point the library group would be
 implementing the standard library itself.
 [...]
 I think it would be best to start with a mailing list and a CVS and
 expand according to what turns out to be necessary.
 [...]
 It's self-feeding.  D can't be mature until it has a good library.  Not
 having a good library decreases maturity over time due to
 reimplementations.  I think I've implemented file stat and directory
 listing six times over the year; the first time was the most
 comprehensive, the rest I just wanted to get the task over with.

Agree 120%. Besides, this demonstrates (as if there were any need to do so) that you're smarter than wanting to type "net.BurtonRadons" hundreds of times just for the glory :-) Ric
Aug 04 2003
prev sibling next sibling parent Frank Wills <fdwills sandarh.com> writes:
Burton Radons wrote:
 
 No automatic linking.  The source defines the libraries it uses.
 

I agree with this. I also think the libraries should be modular, so that a person could include "d.file" or "d.stream" but not include "d.win32" or "d.string". I have experienced trying to import my own module for something and having to mangle the name of routines or classes from what I prefer to prevent collision with phobos.
Aug 04 2003
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
I want to encourage everyone to help out with the library. My primary focus,
as you all have guessed by now, is making the compiler itself the best it
can be. Phobos has been a bit neglected as a result. I, of course, will take
on the task of the necessary runtime support for the language semantics,
such as making sure the exception handling stack unwinder works. But the
stuff that makes a library full and great, I'm not too good at.

A couple philosophical points on what I think makes a good library:

1) Loose coupling. This is important so that small apps can be created. In
Java, it turned out that every class was dependent on every other class, so
the smallest app pulled in the entire library. Library modules should be as
decoupled as practical. Calling a directory function shouldn't pull in 100k
of bloat.

2) The C standard library is not a good module to be emulated. While the C
standard library should be available via c.stdio, that's it. C file I/O is
particularly slow due to the double buffering it requires.

3) Core library stuff should be easilly implementable on both win32 and
linux. With those two covered, it shouldn't be too much trouble to take it
anywhere.

4) Modules should be a thin veneer over operating system API's. This will
alleviate the temptation of bypassing them and calling the OS directly.

5) Performance matters.

6) Size matters.

7) Make use of the in, out, invariant and unittest features, especially the
unittest.

8) As always, be real careful about copyrights. A standard library that's
encumbered by disinterested third party copyrights will be a boat anchor
holding us all back. D needs to be IP clean, it's the right thing to do.
When in any doubt, write it from scratch.

9) Put your name in the code you write! You'll be famous as one of the D
pioneers!

I think we can learn a lot from how the Python libraries are organized.
Their creators seem to know what they're doing <g>.
Aug 16 2003
next sibling parent reply "Charles Sanders" <sanders-consulting comcast.net> writes:
Great I was wondering about this, I remember alot of activity but don't
remember what became of it.

I'd really like to see this started also, I can offer webspace, CVS and
whatever else you need (within reason ;) ).  I'd also like to contribute,
there is alot of talent on this newsgroup who would be interested in this ?

I'm not trying to elect myself as leader to this, I just want to see it get
off the ground.

Thanks, lets hear some ideas!

Charles


"Walter" <walter digitalmars.com> wrote in message
news:bhkq1t$1urm$1 digitaldaemon.com...
 I want to encourage everyone to help out with the library. My primary

 as you all have guessed by now, is making the compiler itself the best it
 can be. Phobos has been a bit neglected as a result. I, of course, will

 on the task of the necessary runtime support for the language semantics,
 such as making sure the exception handling stack unwinder works. But the
 stuff that makes a library full and great, I'm not too good at.

 A couple philosophical points on what I think makes a good library:

 1) Loose coupling. This is important so that small apps can be created. In
 Java, it turned out that every class was dependent on every other class,

 the smallest app pulled in the entire library. Library modules should be

 decoupled as practical. Calling a directory function shouldn't pull in

 of bloat.

 2) The C standard library is not a good module to be emulated. While the C
 standard library should be available via c.stdio, that's it. C file I/O is
 particularly slow due to the double buffering it requires.

 3) Core library stuff should be easilly implementable on both win32 and
 linux. With those two covered, it shouldn't be too much trouble to take it
 anywhere.

 4) Modules should be a thin veneer over operating system API's. This will
 alleviate the temptation of bypassing them and calling the OS directly.

 5) Performance matters.

 6) Size matters.

 7) Make use of the in, out, invariant and unittest features, especially

 unittest.

 8) As always, be real careful about copyrights. A standard library that's
 encumbered by disinterested third party copyrights will be a boat anchor
 holding us all back. D needs to be IP clean, it's the right thing to do.
 When in any doubt, write it from scratch.

 9) Put your name in the code you write! You'll be famous as one of the D
 pioneers!

 I think we can learn a lot from how the Python libraries are organized.
 Their creators seem to know what they're doing <g>.

Aug 16 2003
next sibling parent reply "Mike Wynn" <mike.wynn l8night.co.uk> writes:
"Charles Sanders" <sanders-consulting comcast.net> wrote in message
news:bhm2ns$3dd$1 digitaldaemon.com...
 Great I was wondering about this, I remember alot of activity but don't
 remember what became of it.

 I'd really like to see this started also, I can offer webspace, CVS and
 whatever else you need (within reason ;) ).  I'd also like to contribute,
 there is alot of talent on this newsgroup who would be interested in this

I always prefered perforce to cvs http://www.perforce.com/ as this is an open source project (does not need to be GPL but does have to contain "Redistribution and use in source and binary forms, with or without modification, are permitted" ) not sure if that is acceptable,Walter what where your plans for the phobos libs licence?
 I'm not trying to elect myself as leader to this, I just want to see it

 off the ground.

find the phobos Stream too much like FILE *, and perfer the Java approach where InputStream is just that. but I've run into a few issues first wchar[] is not very well supported Exception for instance can not have a wchar[] msg seems to me that it would be best if all apis used wchar as char-> wchar ([] or not) can be performed without loss of information (the converse not). the wchar windows api calls is missing too (well as is a lot of the win32 API) that is solvable by using the ported headers I've done and getting them tested (I'm certain that there may be alignment and other errors in there there is nearly a meg of code however I do not believe that it is realy legal for me to redistribute the work I've done (Bill if your reading this, and want to sue me I'll only accept the summons if you deliver it in person!) (I've attached the MS SDK licence) from what I read I can redist modified code only if I can make an object lib (not realy helpful) Walter I assume you have a licence to redistribute the MS headers, does it cover redist of modified headers and does it extend to a) ppl outside your company b) the latest SDK ? otherwise the first task as I see it it so get a licence to port the MS headers without that we are dead in the water. (if case a false I wonder if we can become unpayed members of the DM staff to get around the licence agreement(s)). I have to revisit python to see how/what the layout is like but module and templates are causing me some grief. again I like the Java way, there is nothing worse (to me) than having to search for where something is. if I want the class phobos.io.InputStream ... I'd like to know A how to get it and B how to import it .. import phobos.io.InputStream; would seem logical or (import phobos.io; maybe) if I'm right about the D modules Object (which is defined in object.d) has the fully qualified name `object.Object` if I start putting each class into a separate file (and if this is going to be a multi developer open source lib I think you'll all agree that, that will be a lot nicer that a wacking great phobos/io.d (or whatever) file with all the stream and other io classes) say I use phobos/io/InputStream.d for InputStream etc its fully qualified name is then phobos.io.InputStream.InputStream; I could make is phobos/base/InputStream.d; => phobos.base.InputStream.InputStream; and have a alias in the phobos/io.d file (alias phobos.base.InputStream.InputStream InputStream;) but thats a lot of typing and prone to errors all to just get phobos.io.InputStream as a fully qualified name and to get the implementation into a file on its own. like templates (which are almost modules within modules) I think there there is too much depth in the D names, I think D needs a way to create a file that only contains one item, be that a template, class, struct or other. so import a.b.c; looks for a/b/c.d as it does now; only the item imported may be a.b.c rather than a.b.c.t.c or a.b.c.c etc;
Aug 16 2003
parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Perhaps what you want is akin to the ability to pick out one name from a =
module, like so:

=3D=3D=3D=3D=3D=3D=3D=3Dfile A.d:=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
module A;
class B {}

...
=3D=3D=3D=3D=3D=3D=3D=3Dfile C.d:=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
module C;

import A.B;  // just bring in class B from module A



Except you want to be able to do away with module A entirely.

What if such a file were missing a module declaration, and the only name =
present in it matches the file name?

=3D=3D=3D=3D=3D=3D=3D=3Dfile B.d:=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
class B {}

...
=3D=3D=3D=3D=3D=3D=3D=3Dfile C.d:=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
module C;

import B;  // just bring in class B from B.d

Hmm.  It seems viable but I'm sure there would be other issues to work =
out.  What if class B needs some "global" support declarations?

A workaround for now might be public imports.

=20
=3D=3D=3D=3D=3D=3D=3D=3Dfile A.d:=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
module A;
class B {}

...
=3D=3D=3D=3D=3D=3D=3D=3Dfile Stuff.d:=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
public import A.B;

...
=3D=3D=3D=3D=3D=3D=3D=3Dfile C.d:=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
module C;

import Stuff.B;  // just bring in class B from A.d, via public import in =
Stuff.d


I seem to recall D used to have this behavior by default, and private =
imports were added to compensate.  So this might still work, I haven't =
checked.  You could pull in everything you need into one big library =
interface module, even though it actually lives in its own module in its =
own file.  But it requires such a library interface module.  That's not =
such a stiff requirement though, as this kind of thing would be mostly =
for library work anyway.

Sean

"Mike Wynn" <mike.wynn l8night.co.uk> wrote in message =
news:bhme5o$jlf$1 digitaldaemon.com...
  like templates (which are almost modules within modules) I think there =
there
  is too much depth in the D names,
  I think D needs a way to create a file that only contains one item, be =
that
  a template, class, struct or other. so import a.b.c; looks for a/b/c.d =
 as
  it does now; only the item imported may be a.b.c
  rather than a.b.c.t.c or a.b.c.c etc;
Aug 17 2003
prev sibling parent "Peter Hercek" <vvp no.post.spam.sk> writes:
You may try this instead of CVS: http://subversion.tigris.org/
Not a final version yet, but usable.
Highlights: it has renames and atomic commit compared to CVS.

"Charles Sanders" <sanders-consulting comcast.net> wrote in message
news:bhm2ns$3dd$1 digitaldaemon.com...
 Great I was wondering about this, I remember alot of activity but don't
 remember what became of it.

 I'd really like to see this started also, I can offer webspace, CVS and
 whatever else you need (within reason ;) ).  I'd also like to contribute,
 there is alot of talent on this newsgroup who would be interested in this ?

 I'm not trying to elect myself as leader to this, I just want to see it get
 off the ground.

 Thanks, lets hear some ideas!

 Charles


 "Walter" <walter digitalmars.com> wrote in message
 news:bhkq1t$1urm$1 digitaldaemon.com...
 I want to encourage everyone to help out with the library. My primary

 as you all have guessed by now, is making the compiler itself the best it
 can be. Phobos has been a bit neglected as a result. I, of course, will

 on the task of the necessary runtime support for the language semantics,
 such as making sure the exception handling stack unwinder works. But the
 stuff that makes a library full and great, I'm not too good at.

 A couple philosophical points on what I think makes a good library:

 1) Loose coupling. This is important so that small apps can be created. In
 Java, it turned out that every class was dependent on every other class,

 the smallest app pulled in the entire library. Library modules should be

 decoupled as practical. Calling a directory function shouldn't pull in

 of bloat.

 2) The C standard library is not a good module to be emulated. While the C
 standard library should be available via c.stdio, that's it. C file I/O is
 particularly slow due to the double buffering it requires.

 3) Core library stuff should be easilly implementable on both win32 and
 linux. With those two covered, it shouldn't be too much trouble to take it
 anywhere.

 4) Modules should be a thin veneer over operating system API's. This will
 alleviate the temptation of bypassing them and calling the OS directly.

 5) Performance matters.

 6) Size matters.

 7) Make use of the in, out, invariant and unittest features, especially

 unittest.

 8) As always, be real careful about copyrights. A standard library that's
 encumbered by disinterested third party copyrights will be a boat anchor
 holding us all back. D needs to be IP clean, it's the right thing to do.
 When in any doubt, write it from scratch.

 9) Put your name in the code you write! You'll be famous as one of the D
 pioneers!

 I think we can learn a lot from how the Python libraries are organized.
 Their creators seem to know what they're doing <g>.


Aug 16 2003
prev sibling next sibling parent Friedrich Dominicus <frido q-software-solutions.com> writes:
Walter wrote:
 I want to encourage everyone to help out with the library. My primary focus,
 as you all have guessed by now, is making the compiler itself the best it
 can be. Phobos has been a bit neglected as a result. I, of course, will take
 on the task of the necessary runtime support for the language semantics,
 such as making sure the exception handling stack unwinder works. But the
 stuff that makes a library full and great, I'm not too good at.
 
 A couple philosophical points on what I think makes a good library:
 
 1) Loose coupling. This is important so that small apps can be created. In
 Java, it turned out that every class was dependent on every other class, so
 the smallest app pulled in the entire library. Library modules should be as
 decoupled as practical. Calling a directory function shouldn't pull in 100k
 of bloat.

tight coupled classes. e.g all the List classes single linked, double linked etc will have features implemented in some base class. But I assume you were not talking about that kind of cohesion.
 
 2) The C standard library is not a good module to be emulated. While the C
 standard library should be available via c.stdio, that's it. C file I/O is
 particularly slow due to the double buffering it requires.

that library regularly and know the Ins/Outs...
 
 3) Core library stuff should be easilly implementable on both win32 and
 linux. With those two covered, it shouldn't be too much trouble to take it
 anywhere.

you talking about well known datastructures? I can't see any problem with a library if it's fully implemented in D. A list implementation will work on "all the platforms"
 
 4) Modules should be a thin veneer over operating system API's. This will
 alleviate the temptation of bypassing them and calling the OS directly.

A very thin layer for "base services" and a lot of convenience libraries.
 
 5) Performance matters.

 
 6) Size matters.

Anyway I would sacrify it quite bunch of the latter points for stability and even more important (IMHO) maintainebility.
 
 7) Make use of the in, out, invariant and unittest features, especially the
 unittest.

 
 8) As always, be real careful about copyrights. A standard library that's
 encumbered by disinterested third party copyrights will be a boat anchor
 holding us all back. D needs to be IP clean, it's the right thing to do.
 When in any doubt, write it from scratch

 
 9) Put your name in the code you write! You'll be famous as one of the D
 pioneers!

development is time consuming and getting libaries consistent is really hard to get right. I suggest checking the naming conventions in Eiffel as a design starting point. I have spend quite some time on library development but are very short on time beeing able to spend on free work.... Regards Friedrich
Aug 18 2003
prev sibling parent Helmut Leitner <helmut.leitner chello.at> writes:
Walter wrote:
 
 I want to encourage everyone to help out with the library. My primary focus,
 as you all have guessed by now, is making the compiler itself the best it
 can be. Phobos has been a bit neglected as a result. I, of course, will take
 on the task of the necessary runtime support for the language semantics,
 such as making sure the exception handling stack unwinder works. But the
 stuff that makes a library full and great, I'm not too good at.
 
 A couple philosophical points on what I think makes a good library:
 
 1) Loose coupling. This is important so that small apps can be created. In
 Java, it turned out that every class was dependent on every other class, so
 the smallest app pulled in the entire library. Library modules should be as
 decoupled as practical. Calling a directory function shouldn't pull in 100k
 of bloat.
 
 2) The C standard library is not a good module to be emulated. While the C
 standard library should be available via c.stdio, that's it. C file I/O is
 particularly slow due to the double buffering it requires.
 
 3) Core library stuff should be easilly implementable on both win32 and
 linux. With those two covered, it shouldn't be too much trouble to take it
 anywhere.
 
 4) Modules should be a thin veneer over operating system API's. This will
 alleviate the temptation of bypassing them and calling the OS directly.
 
 5) Performance matters.
 
 6) Size matters.
 
 7) Make use of the in, out, invariant and unittest features, especially the
 unittest.
 
 8) As always, be real careful about copyrights. A standard library that's
 encumbered by disinterested third party copyrights will be a boat anchor
 holding us all back. D needs to be IP clean, it's the right thing to do.
 When in any doubt, write it from scratch.
 
 9) Put your name in the code you write! You'll be famous as one of the D
 pioneers!
 
 I think we can learn a lot from how the Python libraries are organized.
 Their creators seem to know what they're doing <g>.

If I try to boil this down, I arrive at: A) The primary design goal is efficiency. Priorities: A.1 Unbloated Executables (thin wrappers to APIs, loose coupling) A.2 Performance is more important than size (help the compiler / in out invariant) A.3 Runtime Size is important, but less than performance B) Secondary design goals B.1 Keep Windows and Linux in mind and on par B.2 Care about safety (unittests!) B.3 Care about copyrights (in doubt? rewrite!) Please correct me, where I'm wrong. Where shall OO fit in? Sometimes objects and object hierarchies result in increased coupling and bloat. -- Helmut Leitner leitner hls.via.at Graz, Austria www.hls-software.com
Aug 26 2003