"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
going
> to work. I think D needs a libraries group (DLG), composed of interested
and
> experienced volunteers, ratified by big W, of course.
Here's one (as long as Walter agrees, that is...)

>
> 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 .
Especially if it works better, and its source is smaller and more readable,
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
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. [...]
>
>  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,
etc.
>  - 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
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.
IMHO, just as real-world apps are going to shape library development, DLG's 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
some
> obvious reasons against. Shoot away.
I had breakfast 2 hours ago, so I have no excuses. :-)

Ric

> 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

"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.
I apologize for the imprecision.

> C++'s biggest advantage(s) over C are RAII and templates. Inheritance, and all the other OO gunk, is just a nice extra.
IIRC, commercial C++ compilers were advertised, from the beginning, as if
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.
Oh,
> and it needs to support equally those who program in "a better C", or who like OOP, or who like generics.
That would be great. Having both stdio and iostreams would not. Just my opinion, anyway.

Ric

> > 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.
> That would be great. Having both stdio and iostreams would not. Just my 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? :)

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

"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

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

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

"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
> hardly
> > > 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
obviously
> 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
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 :-)

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

Agreed

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

Quite the contrary

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

"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 ...
Only one. M$ is the devil. ;-)

Ric