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

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

"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

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

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.

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

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

"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.
You're right, but I think times have changed enough. When C++ was born, OOP (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
they
> are only visible to the D compiler.
Please, no! :-) Reintroducing the preprocessor would mean reintroducing
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.
I agree: it needs the best standard library ever seen. So let's make it! :-)

Ric

"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
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.
Why not dropping the C RTL *at all*? It would look more like a serious
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

> You're right, but I think times have changed enough. When C++ was born,
OOP
> (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.