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.

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

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

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

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.

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

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

Hehe, i like phobos too btw.

> (a) thought it
> worthwhile trying to get some structure to the arbitrary individual
efforts
> 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
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.
> >
> >
>
>

"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

"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