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

"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

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

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.

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

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

"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
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?)
>
There is also quite a bit interest in Java for embedded apps (as in embedded
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)

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

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

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

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? ;)

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

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