www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D: A language without focus

reply gabe <gabe_member pathlink.com> writes:
I've been reading these posts for a while now, and going over the documentation,
and discovering some of the tools, and a few things have jumped out at me about
the D language and the D community:

Arrow One: The Message
The reason one language succeeds and another language fails has everything to do
with the marketing of the language. Look at Java -- there's a language that

uncomfortable for people who knew what a computer did and wanted the computer to
do just that (and only that). And yet, Java has succeeded, not only through
their bankroll, but through the packaging of what they do -- providing a unified
and coherent source of information, documentation, tutorials, compiler,
debugger, build tools, packaging tools, networking tools, and system analysis
tools. Each one of these things is a singular effort, unremarkable on the whole,
but packaged together, they provide a compelling and remarkable interface for
programmers desperately looking to combine functionality with ease of use. On a
similar note, look at Python: there's a language with decent libraries,
excellent syntactical clarity, tons of documentation and tutorials, and an open
source license that pleases the hackers while not scaring away businesses with
implementation worries -- if something breaks, they know they have the community
and their own resources to fix it.

None of those things can really be said for D. First, you don't have a fully
functional, stress-tested compiler. Second, you have poor documentation, and
what documentation you do have is either written tersely, poorly, or scattered
to hell-and-gone. Third, you have absolutely no focus: there are dozens of
projects out there planning to build the 'next big utility/tool/ide/whatever',
but hardly any of them seem to be terribly concerned with the fact that D's
libraries rest on pretty shakey ground. In short, the D library is a joke. Have
any of you perused the glibc recently, or the java.* packages? Notice anything
interesting about these projects? If you thought something like 'this has a
stunning wealth of library functionality and documentation', you'll probably see
where I'm going with this. We're not talking about advanced JavaBeans and
ServerFaces, gtkhtml+, or any one of a dozen other amazingly diverse and
specialized fields -- we're talking about the bare essentials here. And nothing
is more important for a language's success than those primary libraries. You can
go over to the 'Ares' forum, where I posted a comment on how a potential library
should be structured. There has to be an interface for programmers, and it's up
to the D community to provide those fundamental interpretations and guidelines.

Arrow Two: Liscenses.
It's all about the liscenses. Take a look around the programming world and look
at the most active developer communities -- the Linux kernel, the Apache
project, the Eclipse project. Each one of these communities shares one startling
thing in common: they are all, from front to back, from first line to last, open
source. Please, focus on this point, because I cannot stress enough the
importance of what this kind of community support can do for a language (PHP, as
people have noted, went from a poor backwater to an IBM flagship in a matter of
3 years through just this same kind of open source initiative). The problem with
D, as I see it, is the ambiguous and somewhat offputting liscensing terms of the
D libraries and compilers.

One of the things that I think a lot of people miss about these open source
projects -- where their strength really lies -- is their appeal to those kinds
of people that adopt whole heartedly the notion of freedom. Freedom to do what
you want when you want with the source code that you have. This kind of freedom
appeals to a huge mass of hackers out there -- hackers who have learned and
weaned themselves on the open source projects of Linux, GNU, and Apache. I think
that's something that most people coming from the Windows side miss when
thinking about this issue. Microsoft, whatever your opinion of it, has trained a
raft of people into beleiving that the only way you make money on something is
by keeping everything to yourself and trying to kill your opponent through
technical starvation. It has led to a 'race condition', if you will, where
everyone wants access but everybody has to wait for the BigGuy to say it's ok. I
think that the point of the D language should be instead to spread it as much as
possible, as freely as possible, to everyone, so that they can see for
themselves how great it really is.

Don't get me wrong -- I don't necessarily hate Microsoft -- but I do think that
a lot of people who use Microsoft have been bamboozled into thinking that the
only way that they're going to acheive commercial success is by assuring
everyone that you're working with that everything will remain strictly
confidential. Secrecy and the ability to deny innovation become the order of the
day. I would merely like to point out that companies like RedHat and Novell, who
have clearly adopted the OSI/FSF mentality, are thriving companies, not least of
all because they acknowledge that sharing is by far the quickest route to
success.

Arrow Third: Solidarity and conformance.

Part of any projects success is it's ability to institude order among a chaotic
group of competing individuals and ideals. This is no less true in D, where a
number of libraries have developed vague interdependancies and marginal or
somewhat disparate coding methodologies. One of the successes of many projects
can be linked back to their development to a uniform interface to outside
consumers. Take Ruby as an example. Initially, it wasn't a very successful
language, on the whole. It struggled in relative obscurity for nearly 7 years
before books and articles started to be written about it. Then, all of a sudden,
it seemed like, something shifted and the community started to amass new
members, contributions increased, and it managed to get over the versioning hump
into 1.8. How can we explain this success? There are a number of explanations, I
believe, but the one that I think speaks best to D's current situation is it's
development of coherent documentation and coding style guidelines. Look at the
Ruby specification for 1.6, and then look at it for 1.8. If you notice anything,
you should notice that the technical guidelines for what was and was not
acceptable coding style became clear -- in essence, language purists began
exercising control over not only the development but the day-to-day use of the
language. Perlisms began to gradually drop out of the language, to be replaced
with more 'idomatic ruby' (i.e., generators and iterators). Also, the coding of
documentation went through the roof -- take a look at www.ruby-doc.org and see
what proper documentation of methods actually looks like. They have everything
that a person could need -- not only an API and documentation, but EXAMPLES OF
USAGE that make how to use the API absolutely clear. Hard as I try, I can't
really say that I've seen the same in D. (For the record, you should also note
Python, started out as a teaching language, and had from the beginning excellent
documentation and EXAMPLES of usage, examples which only got better and more
advanced as the libraries themselves were refined.) Now, all of this isn't to
say that you should write a dozen tutorials per method when you're writing
classes, but there needs to be a quick and coherent way to organize your
information so that other people have more than just method declarations to use.
This leads me to my biggest and most overarching concern as to why D will never
take off as a language -- nobody knows how to write good documentation. And it
doesn't help that the D documentation guidelines aren't that good. Frankly, it
should be much clearer what constitutes a comment and what doesn't -- as well as
what should be included where when creating documentation files. The whole hash
pair of "XXX: xxx" doesn't really work for me -- or for a lexical parser in
creating complex and properly formatted documents, really. If you want to make D
a more palatable language, it's time that it grow up a little and start
accepting the complexities of coding 'in the round', as it were. We need to
embrace the Unicode roots of D source files and begin to plan for XML document
creation. We need to find/create a parser that will work on XML-D documents and
create the appropriate documentation -- be they xhtml docs, pdfs, dvis --
whatever. D needs to learn the cardinal rule of building a language library: if
people can't understand and easily assimilate exactly what it is you want to do,
they're not going to care.

Exclamation Solutions:
I would like to get involved in the D community in developing the tools that
will make D a truly great language. To make that possible, however, we need to
add a centralizing force and focus to the disparate goals of the project. First,
we need to design some kind of mission statement -- something that uniquely
defines our goals as a community and as a group of programmers devoted to making
D a better language for everyone to use. Second, we need to decide on some goals
-- goals that will help us realize our mission by making it easer for people to
come to D from other languages (or even there first language!). Third, we need
to organize ourselves into groups that can work on aspects of the mission and
can communicate easily to one another. This means that we need redundancy in
projects (so that if someone leaves, someone else can take over),
democratization across the group (so that API's and tools can have community
input), and distributied responsibilites for all members (so that each person
feels that they belong through to the group -- not merely because they say they
do, but because they have earned the respect and the trust of their fellow
members). In short, D should be a language where the community that bands around
it is one of openness, respect, and excited collaboration.

I would like to post some more ideas about this, and I'd like to start
organizing those people who are interested in joining together. I'd like to hear
back from the community about this. I'd like to hear back from people excited
about making D the best possible language it can be -- and making programming in
D an absolute joy.

I look forward to hearing from you! 
_________________
New to the land of D, but I like the look of the place.
-Gabe
Apr 26 2006
next sibling parent Hasan Aljudy <hasan.aljudy gmail.com> writes:
gabe wrote:

 I would like to post some more ideas about this, and I'd like to start
 organizing those people who are interested in joining together. I'd like to
hear
 back from the community about this. I'd like to hear back from people excited
 about making D the best possible language it can be -- and making programming
in
 D an absolute joy.
 
 I look forward to hearing from you! 
 _________________
 New to the land of D, but I like the look of the place.
 -Gabe
 


That makes alot of perfect sense.
We need someone to start and take the initiative, I'd be happy to join 
in and help with whatever I can.
Apr 26 2006
prev sibling next sibling parent reply kris <foo bar.com> writes:
gabe wrote:
[snip]

 I would like to post some more ideas about this, and I'd like to start
 organizing those people who are interested in joining together. I'd like to
hear
 back from the community about this. I'd like to hear back from people excited
 about making D the best possible language it can be -- and making programming
in
 D an absolute joy.
 
 I look forward to hearing from you! 
 _________________
 New to the land of D, but I like the look of the place.
 -Gabe


Regarding the libraries, I fully agree ~ that's the reason Mango exists. 
Everyone has always been welcome to join in there :)
Apr 26 2006
parent Kyle Furlong <kylefurlong gmail.com> writes:
kris wrote:

 gabe wrote:
 [snip]

 I would like to post some more ideas about this, and I'd like to start
 organizing those people who are interested in joining together. I'd 
 like to hear
 back from the community about this. I'd like to hear back from people 
 excited
 about making D the best possible language it can be -- and making 
 programming in
 D an absolute joy.

 I look forward to hearing from you! _________________
 New to the land of D, but I like the look of the place.
 -Gabe


 
 Regarding the libraries, I fully agree ~ that's the reason Mango exists. 
 Everyone has always been welcome to join in there :)
 
 
 
 


Lets try to avoid this though:

GRUMBLE

GRand Unified Massively Bloated Library Extravaganza

:D

Rather lets have... GRULE? Yuck.
Apr 26 2006
prev sibling next sibling parent reply clayasaurus <clayasaurus gmail.com> writes:
Disclaimer: 21 year old student who just uses D for a hobby.

gabe wrote:

 
 Arrow One: The Message


The D language does have docs, tutorials, a compiler, and build tools. D 
does have a debugger, but not 100% (GDB and windb). I guess D has 
potentially as many networking tools as C/C++, it just requires effort 
to port over. For system analysis, does code coverage count/profiler 
count? While D doesn't have as many options as Java (and doesn't have 
support of Sun), it is possible to get by on D. D also has an Open 
Source compiler(GDC), so I don't think 'closed source' is a D problem. I 
think D's biggest lack of adoption stems from is 'beta' status, all of 
us here are early adopters. I'm not sure about 'packaging tools,' I 
thought about installers but those are language independent. In 
addition, the D community is very resourceful with helping others use 
the language, I still ask questions every once and a while and I get 
prompt responses back.



 None of those things can really be said for D. First, you don't have a fully
 functional, stress-tested compiler. 


It has gone through a lot of stress testing, just look at Dstress or the 
bugs list and change log. D is fairly stable.


Second, you have poor documentation, and
 what documentation you do have is either written tersely, poorly, or scattered
 to hell-and-gone. 


I've never had a problem with it, but maybe I'm just a newbie. Care to 
give specifics?


 Third, you have absolutely no focus: there are dozens of
 projects out there planning to build the 'next big utility/tool/ide/whatever',
 but hardly any of them seem to be terribly concerned with the fact that D's
 libraries rest on pretty shakey ground. 


Except Ares and Mango perhaps that realize D's libraries are on shaky 
ground?

I myself I am not trying to write the next big 'thing,' I simply use it 
and open my source, but the libraries have been good to me, at least.


 In short, the D library is a joke. 





I wouldn't consider Phobos a joke, but maybe I'm not knowledgeable 
enough on the subject.


 Have
 any of you perused the glibc recently, or the java.* packages? Notice anything
 interesting about these projects? If you thought something like 'this has a
 stunning wealth of library functionality and documentation', you'll probably
see
 where I'm going with this. We're not talking about advanced JavaBeans and
 ServerFaces, gtkhtml+, or any one of a dozen other amazingly diverse and
 specialized fields -- we're talking about the bare essentials here. 


If we are talking about bare essentials, then how has anyone been able 
to do anything at all with D? Do we all just look at phobo's source? 
Maybe the docs could use a bit more work, however they work fine for me.


 And nothing
 is more important for a language's success than those primary libraries. You
can
 go over to the 'Ares' forum, where I posted a comment on how a potential
library
 should be structured. There has to be an interface for programmers, and it's up
 to the D community to provide those fundamental interpretations and guidelines.


True. Good things take time, we have Phobos now and Ares later.


 
 Arrow Two: Liscenses.
 It's all about the liscenses. Take a look around the programming world and look
 at the most active developer communities -- the Linux kernel, the Apache
 project, the Eclipse project. Each one of these communities shares one
startling
 thing in common: they are all, from front to back, from first line to last,
open
 source. 


GDC is a full D compiler implementation that is 100% Open Source.


 The problem with
 D, as I see it, is the ambiguous and somewhat offputting liscensing terms of
the
 D libraries and compilers.


Phobos license: public domain and artistic, what's wrong there?
GDC: GPL (i think)


 Don't get me wrong -- I don't necessarily hate Microsoft -- but I do think that
 a lot of people who use Microsoft have been bamboozled into thinking that the
 only way that they're going to acheive commercial success is by assuring
 everyone that you're working with that everything will remain strictly
 confidential. 


I don't think Walter's in this for commercial success, but rather for 
respect, or maybe because he's spent too long on C++, I don't really 
know. However, if Walter were like Microsoft we would have no linux 
support and the front end would be closed source.


 Arrow Third: Solidarity and conformance.
 


Agree, I think. :-P


 
 Exclamation Solutions:


Agree here too: We need to share a common vision.


 
 I would like to post some more ideas about this, and I'd like to start
 organizing those people who are interested in joining together. I'd like to
hear
 back from the community about this. I'd like to hear back from people excited
 about making D the best possible language it can be -- and making programming
in
 D an absolute joy.


Ut oh, sounds like a committee. It is time? Or are you simply trying to 
rally the open source efforts? :-P
Apr 26 2006
next sibling parent Dave <Dave_member pathlink.com> writes:
In article <e2p5g7$2mnk$1 digitaldaemon.com>, clayasaurus says...

Disclaimer: 21 year old student who just uses D for a hobby.


I'm twice your age, and think you show wisdom beyond your years <g>


gabe wrote:

 


It has gone through a lot of stress testing, just look at Dstress or the 
bugs list and change log. D is fairly stable.


Yes - I can't believe the amount of exemplary work Thomas Kuehn has done in
order to provide this. I've never been involved in commercial language
development, but I'd have to guess that D probably has better QC through DStress
than any other language in a similiar stage of development, ever. The guy even
provides a regression report after every release. Amazing.

To a casual observer, D may look unstable, but much of that is because of the
extraordinary quality of the regulars in this 'DUG' who push the compiler to
it's limits (and because D is pushing the envelope in some areas). All that ever
gets reported are the bugs, not the successes which looks a lot worse than it
really is if one is paying attention.

There are really no show-stoppers to the current tools. There is nothing in the
compiler that will not allow an end-result comparable to what you could do with,
say, GCC.


Second, you have poor documentation, and
 what documentation you do have is either written tersely, poorly, or scattered
 to hell-and-gone. 


I've never had a problem with it, but maybe I'm just a newbie. Care to 
give specifics?


That says it all - you're a 'newbie' (your words) yet you find the docs. usable.
There really isn't all that much missing from the docs. if you take the time to
RTFM. I don't get the scattered part either:

http://digitalmars.com/d/index.html

You can get to everything off of that page.

I think one suggestion would take care of a lot of the perception of "2nd class
citizen" status for D along with the idea that things are scattered: For Walter
to get a new domain soley for D and then redesign the site along the lines of,
say, ActiveState.


 Third, you have absolutely no focus: there are dozens of
 projects out there planning to build the 'next big utility/tool/ide/whatever',
 but hardly any of them seem to be terribly concerned with the fact that D's
 libraries rest on pretty shakey ground. 


Except Ares and Mango perhaps that realize D's libraries are on shaky 
ground?

I myself I am not trying to write the next big 'thing,' I simply use it 
and open my source, but the libraries have been good to me, at least.


Me too - there is a good, basic library provided by phobos. In fact, I'd rather
work with phobos than the std. C library because I think it's layed out better.
I even find it more intuitive, yet I've done a lot more with the C lib.


 In short, the D library is a joke. 





I wouldn't consider Phobos a joke, but maybe I'm not knowledgeable 
enough on the subject.


Good points - why is it considered a 'joke'. I think you are correct in asking
if the OP's ever really used it.
Apr 27 2006
prev sibling parent reply John Reimer <terminal.node gmail.com> writes:
clayasaurus wrote:

<snip>


 Second, you have poor documentation, and
 what documentation you do have is either written tersely, poorly, or 
 scattered
 to hell-and-gone. 


 
 I've never had a problem with it, but maybe I'm just a newbie. Care to 
 give specifics?
 



I just want to point out that Clay is a long time D devotee and has been 
a loyal follower and contributer for a fair amount of time in the D 
community (years now?).  He's actually being extremely modest here to 
call himself a "newbie."  I was surprised that he still considers 
himself that at this point in the game because he just lowered my own 
level to uber-newbie by labeling himself such... :)

I already respect this young fellow as one of the foundations of the D 
community.  He's industrious and committed and has contributed much in 
the form of bug reports, projects, and help in this newsgroup and on 
dsource.org forums.

I don't take his words lightly. In demonstration of non-typical youthful 
exuberance :), Clay channels his energy into setting an example of 
discreetly offering his opinion and respectfully answering posts.  He's 
a careful and moderate poster: I don't recall him ever plaster-posting 
loads of grating pontifications as is the tendency of some.

Tip of the hat to you, Clay. Keep up the good work! :)

-JJR
Apr 28 2006
parent Kyle Furlong <kylefurlong gmail.com> writes:
John Reimer wrote:

 clayasaurus wrote:
 
 <snip>
 

 Second, you have poor documentation, and
 what documentation you do have is either written tersely, poorly, or 
 scattered
 to hell-and-gone. 


 I've never had a problem with it, but maybe I'm just a newbie. Care to 
 give specifics?


 
 
 I just want to point out that Clay is a long time D devotee and has been 
 a loyal follower and contributer for a fair amount of time in the D 
 community (years now?).  He's actually being extremely modest here to 
 call himself a "newbie."  I was surprised that he still considers 
 himself that at this point in the game because he just lowered my own 
 level to uber-newbie by labeling himself such... :)
 
 I already respect this young fellow as one of the foundations of the D 
 community.  He's industrious and committed and has contributed much in 
 the form of bug reports, projects, and help in this newsgroup and on 
 dsource.org forums.
 
 I don't take his words lightly. In demonstration of non-typical youthful 
 exuberance :), Clay channels his energy into setting an example of 
 discreetly offering his opinion and respectfully answering posts.  He's 
 a careful and moderate poster: I don't recall him ever plaster-posting 
 loads of grating pontifications as is the tendency of some.
 
 Tip of the hat to you, Clay. Keep up the good work! :)
 
 -JJR


Love and huggles for John too! :D
Apr 28 2006
prev sibling next sibling parent "Boris Wang" <nano.kago hotmail.com> writes:
D is a language begin in the world of windows.

The world of Windows is so different than the world of *nix,

there is no opensource, no cooperation, no realy hackers, except for java.


"gabe" <gabe_member pathlink.com>
дÈëÏûÏ¢ÐÂÎÅ:e2oom6$21g4$1 digitaldaemon.com...

 I've been reading these posts for a while now, and going over the 
 documentation,
 and discovering some of the tools, and a few things have jumped out at me 
 about
 the D language and the D community:

 Arrow One: The Message
 The reason one language succeeds and another language fails has everything 
 to do
 with the marketing of the language. Look at Java -- there's a language 
 that

 uncomfortable for people who knew what a computer did and wanted the 
 computer to
 do just that (and only that). And yet, Java has succeeded, not only 
 through
 their bankroll, but through the packaging of what they do -- providing a 
 unified
 and coherent source of information, documentation, tutorials, compiler,
 debugger, build tools, packaging tools, networking tools, and system 
 analysis
 tools. Each one of these things is a singular effort, unremarkable on the 
 whole,
 but packaged together, they provide a compelling and remarkable interface 
 for
 programmers desperately looking to combine functionality with ease of use. 
 On a
 similar note, look at Python: there's a language with decent libraries,
 excellent syntactical clarity, tons of documentation and tutorials, and an 
 open
 source license that pleases the hackers while not scaring away businesses 
 with
 implementation worries -- if something breaks, they know they have the 
 community
 and their own resources to fix it.

 None of those things can really be said for D. First, you don't have a 
 fully
 functional, stress-tested compiler. Second, you have poor documentation, 
 and
 what documentation you do have is either written tersely, poorly, or 
 scattered
 to hell-and-gone. Third, you have absolutely no focus: there are dozens of
 projects out there planning to build the 'next big 
 utility/tool/ide/whatever',
 but hardly any of them seem to be terribly concerned with the fact that 
 D's
 libraries rest on pretty shakey ground. In short, the D library is a joke. 
 Have
 any of you perused the glibc recently, or the java.* packages? Notice 
 anything
 interesting about these projects? If you thought something like 'this has 
 a
 stunning wealth of library functionality and documentation', you'll 
 probably see
 where I'm going with this. We're not talking about advanced JavaBeans and
 ServerFaces, gtkhtml+, or any one of a dozen other amazingly diverse and
 specialized fields -- we're talking about the bare essentials here. And 
 nothing
 is more important for a language's success than those primary libraries. 
 You can
 go over to the 'Ares' forum, where I posted a comment on how a potential 
 library
 should be structured. There has to be an interface for programmers, and 
 it's up
 to the D community to provide those fundamental interpretations and 
 guidelines.

 Arrow Two: Liscenses.
 It's all about the liscenses. Take a look around the programming world and 
 look
 at the most active developer communities -- the Linux kernel, the Apache
 project, the Eclipse project. Each one of these communities shares one 
 startling
 thing in common: they are all, from front to back, from first line to 
 last, open
 source. Please, focus on this point, because I cannot stress enough the
 importance of what this kind of community support can do for a language 
 (PHP, as
 people have noted, went from a poor backwater to an IBM flagship in a 
 matter of
 3 years through just this same kind of open source initiative). The 
 problem with
 D, as I see it, is the ambiguous and somewhat offputting liscensing terms 
 of the
 D libraries and compilers.

 One of the things that I think a lot of people miss about these open 
 source
 projects -- where their strength really lies -- is their appeal to those 
 kinds
 of people that adopt whole heartedly the notion of freedom. Freedom to do 
 what
 you want when you want with the source code that you have. This kind of 
 freedom
 appeals to a huge mass of hackers out there -- hackers who have learned 
 and
 weaned themselves on the open source projects of Linux, GNU, and Apache. I 
 think
 that's something that most people coming from the Windows side miss when
 thinking about this issue. Microsoft, whatever your opinion of it, has 
 trained a
 raft of people into beleiving that the only way you make money on 
 something is
 by keeping everything to yourself and trying to kill your opponent through
 technical starvation. It has led to a 'race condition', if you will, where
 everyone wants access but everybody has to wait for the BigGuy to say it's 
 ok. I
 think that the point of the D language should be instead to spread it as 
 much as
 possible, as freely as possible, to everyone, so that they can see for
 themselves how great it really is.

 Don't get me wrong -- I don't necessarily hate Microsoft -- but I do think 
 that
 a lot of people who use Microsoft have been bamboozled into thinking that 
 the
 only way that they're going to acheive commercial success is by assuring
 everyone that you're working with that everything will remain strictly
 confidential. Secrecy and the ability to deny innovation become the order 
 of the
 day. I would merely like to point out that companies like RedHat and 
 Novell, who
 have clearly adopted the OSI/FSF mentality, are thriving companies, not 
 least of
 all because they acknowledge that sharing is by far the quickest route to
 success.

 Arrow Third: Solidarity and conformance.

 Part of any projects success is it's ability to institude order among a 
 chaotic
 group of competing individuals and ideals. This is no less true in D, 
 where a
 number of libraries have developed vague interdependancies and marginal or
 somewhat disparate coding methodologies. One of the successes of many 
 projects
 can be linked back to their development to a uniform interface to outside
 consumers. Take Ruby as an example. Initially, it wasn't a very successful
 language, on the whole. It struggled in relative obscurity for nearly 7 
 years
 before books and articles started to be written about it. Then, all of a 
 sudden,
 it seemed like, something shifted and the community started to amass new
 members, contributions increased, and it managed to get over the 
 versioning hump
 into 1.8. How can we explain this success? There are a number of 
 explanations, I
 believe, but the one that I think speaks best to D's current situation is 
 it's
 development of coherent documentation and coding style guidelines. Look at 
 the
 Ruby specification for 1.6, and then look at it for 1.8. If you notice 
 anything,
 you should notice that the technical guidelines for what was and was not
 acceptable coding style became clear -- in essence, language purists began
 exercising control over not only the development but the day-to-day use of 
 the
 language. Perlisms began to gradually drop out of the language, to be 
 replaced
 with more 'idomatic ruby' (i.e., generators and iterators). Also, the 
 coding of
 documentation went through the roof -- take a look at www.ruby-doc.org and 
 see
 what proper documentation of methods actually looks like. They have 
 everything
 that a person could need -- not only an API and documentation, but 
 EXAMPLES OF
 USAGE that make how to use the API absolutely clear. Hard as I try, I 
 can't
 really say that I've seen the same in D. (For the record, you should also 
 note
 Python, started out as a teaching language, and had from the beginning 
 excellent
 documentation and EXAMPLES of usage, examples which only got better and 
 more
 advanced as the libraries themselves were refined.) Now, all of this isn't 
 to
 say that you should write a dozen tutorials per method when you're writing
 classes, but there needs to be a quick and coherent way to organize your
 information so that other people have more than just method declarations 
 to use.
 This leads me to my biggest and most overarching concern as to why D will 
 never
 take off as a language -- nobody knows how to write good documentation. 
 And it
 doesn't help that the D documentation guidelines aren't that good. 
 Frankly, it
 should be much clearer what constitutes a comment and what doesn't -- as 
 well as
 what should be included where when creating documentation files. The whole 
 hash
 pair of "XXX: xxx" doesn't really work for me -- or for a lexical parser 
 in
 creating complex and properly formatted documents, really. If you want to 
 make D
 a more palatable language, it's time that it grow up a little and start
 accepting the complexities of coding 'in the round', as it were. We need 
 to
 embrace the Unicode roots of D source files and begin to plan for XML 
 document
 creation. We need to find/create a parser that will work on XML-D 
 documents and
 create the appropriate documentation -- be they xhtml docs, pdfs, dvis --
 whatever. D needs to learn the cardinal rule of building a language 
 library: if
 people can't understand and easily assimilate exactly what it is you want 
 to do,
 they're not going to care.

 Exclamation Solutions:
 I would like to get involved in the D community in developing the tools 
 that
 will make D a truly great language. To make that possible, however, we 
 need to
 add a centralizing force and focus to the disparate goals of the project. 
 First,
 we need to design some kind of mission statement -- something that 
 uniquely
 defines our goals as a community and as a group of programmers devoted to 
 making
 D a better language for everyone to use. Second, we need to decide on some 
 goals
 -- goals that will help us realize our mission by making it easer for 
 people to
 come to D from other languages (or even there first language!). Third, we 
 need
 to organize ourselves into groups that can work on aspects of the mission 
 and
 can communicate easily to one another. This means that we need redundancy 
 in
 projects (so that if someone leaves, someone else can take over),
 democratization across the group (so that API's and tools can have 
 community
 input), and distributied responsibilites for all members (so that each 
 person
 feels that they belong through to the group -- not merely because they say 
 they
 do, but because they have earned the respect and the trust of their fellow
 members). In short, D should be a language where the community that bands 
 around
 it is one of openness, respect, and excited collaboration.

 I would like to post some more ideas about this, and I'd like to start
 organizing those people who are interested in joining together. I'd like 
 to hear
 back from the community about this. I'd like to hear back from people 
 excited
 about making D the best possible language it can be -- and making 
 programming in
 D an absolute joy.

 I look forward to hearing from you!
 _________________
 New to the land of D, but I like the look of the place.
 -Gabe
Apr 26 2006
prev sibling next sibling parent reply nick <nick.atamas gmail.com> writes:
Sounds to me as though you are really eager to have D1.0 right this
moment and you are frustrated with all the things that aren't working
just the way you like them.

gabe wrote:

 I've been reading these posts for a while now, and going over the
documentation,
 and discovering some of the tools, and a few things have jumped out at me about
 the D language and the D community:


......SNIP........

 
 I would like to post some more ideas about this, and I'd like to start
 organizing those people who are interested in joining together. I'd like to
hear
 back from the community about this. I'd like to hear back from people excited
 about making D the best possible language it can be -- and making programming
in
 D an absolute joy.
 
 I look forward to hearing from you! 
 _________________
 New to the land of D, but I like the look of the place.
 -Gabe
Apr 26 2006
parent reply gabe <gabe_member pathlink.com> writes:
In article <e2pgfg$4s3$1 digitaldaemon.com>, nick says...

Sounds to me as though you are really eager to have D1.0 right this
moment and you are frustrated with all the things that aren't working
just the way you like them.


Well, you're only partially right about that.  I do have some dissapointment
that things don't exactly 'work'.  I think that anything that doesn't just
'work' for people coming to the language (or even working in it for a long
time), tends to make D look inflexible and amaturish compared to other efforts.
That is not to say that D is in any way either of those things -- I think it has
the potential to be very robust and quite user-friendly, but in order for the
language to really succeed, you're going to have to convince more than just me.
In order to succeed, you're going to have to convince all the other beginning,
10 cent hackers out there that D is a language of the future -- that it HAS a
future -- at the center of a stable and growing community.  All this feeds into
the notions that I outlined in my first message.  Design a system -- not just
part of the language -- to foster growth and stability, and people will search
YOU out, and not the other way around.  The keys to that system revolves around
finding what is necessary within the community and then designing toward those
goals.

So, with that in mind, let me offer up some ideas that I have been ruminating
upon.

First: The Build Mechanism
I've tried to play around a little with Build, and I think to a certain extent
it's a fine tool.  What it lacks, I feel is not so much the ability to compile a
series of programs but to really bring the end product together for users.  To
clarify: what build doesn't really seem to do is build in user-friendliness into
the libraries.  To a large extent, I think this more the fault of documentation
than of Build.  In my idea of a build tool, the documentation is far more
succinct and far more powerful; it leverages the native unicode support of D
against XML.  Now, I know XML is everyone's favorite language to hate, as it
quickly becomes quite complicated if not done well, but I feel that by using a
basic and standardized syntax, D could quickly develop a usable (online)
documentation system that exists in real-time with the development code itself.
Allow me to elaborate with the following, very rough example

---D source---
/++doc.xml
<doc lang="en_us">
<author name="Danger Duck" date="01.12.07" liscense="GPLv3" />
<method>
<param>long sec_uid</param>
<desc>A fake variable passed to secure this message against flame</desc>
<return>A <link lib="util.fire.safety">FlameRetardantSuit</link> to protect user
against singing</return>
</method>
<example><![CDATA[[
{
Suit s = Suit.getRetardantSuit(my_long_security_id); /* pass in unique id*/
s.buttonUpItsGonnaGetHotInHere(); /* Lock yourself in the vault */
s.waitForAllClear(clear_handler); /* Whew!, saved my tail feathers again! */
s.divest(); /* release the lock */
}
]]>
</example>
<tutorial><![CDATA[
You have to know what you're doing when you use this object.  Put it on too
soon, and you may overheat and cook your own goose.  Put it on too late, and
those henpecked farmers may get your gizzard.  As you can see from this example
<example ref="inline" /> the feathers are really flying.  Use it carefully,
though, and it'll all be like water off a duck's back.

I apologize for all the fowl phrases.
]]>
</tutorial>
</doc>
<doc lang="fr_fr">
<method nom_de_poulet="Danger Duck" date="01.12.07" permet="GPLv3">
<param>long sec_uid</param>
<usage>Parlez le francais mieux de moi</usage>
<rentre>Quelquechose de 'honk'</rentre>
<exemple>
..etc., etc., etc., ...
</doc>
+/
public FlameRetardantSuit getFlameRetardantSuit(long sec_uid) {
...
}

--- end D ---
As you can see, it's possible to implement documentation at a level that can be
directly transformed into any number of kinds of documentation.   You could
publish the API and the examples on the Web; you could publish a library
reference in PDF; you could distribute a localized tutorial in every language
imaginable.  The possibilities, frankly, for brining in people form around the
world are virtually limitless.  I know that this probably seems like way too
much documentation for a single method, but I think the idea is essentially
there -- it just has to be mined efffectively.

Second:
I've heard back from a few people about having a small core library.  I can
certainly respect that: coming from Java, I know what it feels like to have a
glut of options.  On the other hand, one of the undeniable draws for a language
is a substantial library of well-tested code.  The functionality of a language
is, in this sense, directly reflected in the composition of its libraries.  To
that end, I would propose a two-tiered solution.  On the first tier, there sits
two basic libraries: 'lang' and 'sys'.  Unlike Java, which hides much of the
implementation details of the system, D users should be allowed the freedom to
deal directly with the hardware and the underlying system when needed.  For this
reason, the sys and the lang packages will supply all of the basic functionality
needed for D to run in any environment.  This should especially appeal to
systems programmers and library implementers, as one can hide a good deal of
existing c code behind some carefully constructed interfaces or superior
packaging.  The 'lang' package, in particular, needs the 'sys' libs in order to
deliver all of the low-level coding required by each operating system, thus, I
believe, releiving even some of the lower details from language implementors.
It should be the case that these two packages are automatically searched and
compiled into any running program, though the top level DPATH may only refer to
'/usr/include/d/', or whatnot.  

The second part of this teir delivers everything else that the core library
lacks, including complicated IO, data structures, utilities, ui components, and
parsers.  I've given a rough outline of what the library might looklike below.
Of course, much of my model liberally samples (i.e. outright steals) from the

-- each language should stand on the shoulders of the one that came before it --
and I think each of those languages are quite good at packaging together
disparate pieces.  Of course, we wouldn't import from d.xxx -- we can drop the
'd.' syntax entirely once the compiler supports native library builds; I always
did resent the whole 'import java....' fiasco.  This seems to be an ok solution
as long as we make sure that we don't conflict with URL domains in these
top-level directories.  

d/
------ BRL - Basic Runtime Library ------
lang
gc
exception
thread
primitives
array
bitarray
string
box
hashmap
compiler
..

sys 
console (for some basic io)
memory
call (hiding system calls, I thought)
lib  (Windows lib, glibc, ... what have you)
..

-------------------------------------------

----- ERL - Extended Runtime Library ------

ext
c
stdio
math
fenv
process
stdarg
stddef
stdlib
string
time
..
c++
..

data (collections/standard data structures, probably via templates)
ArrayList
Stack
Queue
LinkedList
DoublyLinkedList
CircularlyLinkedList
BinaryTree
Map
..

util
compress (protocols for bzip, gzip, tar etc.)
logging
date
random
..

os (or 'kaos', for nameing conflicts [kernel and o/s] -- hsa mythic overtones)
posix
c
windows
c
..
com
..
dotnet
linux
c
..
kernel (???)
..
userland (???)
titan
minix
..

security
crypt
md5
sha1
..
dgp (a port of gnu pgp might be very helpful, if signing mail, for instance)
invoke (secure calls to the system? 'Titan' might find this useful)
ssl
key

math
complex
fourier
boolean
..

ui 
curses
thea (D language graphical system based on the qt framework)
opengl
window
..
..

text
encoding
unicode
ansi
codepage
locale
format
regex
parsers
CVS
yaml
yacc (?)
..

sql
dbi (database interface abstraction)
vendor (specific vendor APIs)
slumber (hibernate or ado api?)
..

io  (or 'dio', to avoid any conflicts)
file
buffer
pipe
stream
..

inet (to deal with local imports like net.chickenplucker.geetar.blah)
socket
server
http
udp
ftp
mail
encoding
protocols
ident
url
uri
..
reactor
svn
..

xml
parsers
validators
xpath
xslt
rpc
soap
..

..

----------------------------------------

One last thing before I slip off to bed: I really want to rally around an open
source license for this project, particularly one that strives for complete
transparency.  Not only does this really promote a sense of sharing and
community, but I feel that it also gives newcomers and old hackers some ideals
to really identify with.  To that end I would suggest the GPL as the starting
point -- possibly even liscenesed under some kind of dual GPL/LGPL liscense.
This kind of transparency, I feel, really invites people to the table in an
egalitarian and communal way.  (Not to mention the fact that putting it under
the GPL opens up the floodworks for linking into other GPL code -- and there's
tons of it.)

I'm sure that I've forgotten a few things in all this, and I think that there's
so much more to say, but I'm tired so I wish you all a fond goodnight and I look
forward to reading your responses in the morning.

Quack!
Gabe
Apr 26 2006
next sibling parent "Alberto Simon" <lugaidster gmail.com> writes:

background and I like the fact that most useful things you need are already 
there in .NET libraries. I like D for the fact that it provides a clean 

language for that matter). Since I believe D is meant to be a productive 
language in that you should only code what you need, I would really like to 
see a productive package (debugger plz!) for it, and if any help is needed I 
would like to offer mine. I hope that everything that is said here on 
doesn't become dust in the wind and that something useful comes from this.

Regards,
Alberto Simon

"gabe" <gabe_member pathlink.com> escribió en el mensaje 
news:e2pnib$eht$1 digitaldaemon.com...

 In article <e2pgfg$4s3$1 digitaldaemon.com>, nick says...

Sounds to me as though you are really eager to have D1.0 right this
moment and you are frustrated with all the things that aren't working
just the way you like them.


 Well, you're only partially right about that.  I do have some 
 dissapointment
 that things don't exactly 'work'.  I think that anything that doesn't just
 'work' for people coming to the language (or even working in it for a long
 time), tends to make D look inflexible and amaturish compared to other 
 efforts.
 That is not to say that D is in any way either of those things -- I think 
 it has
 the potential to be very robust and quite user-friendly, but in order for 
 the
 language to really succeed, you're going to have to convince more than 
 just me.
 In order to succeed, you're going to have to convince all the other 
 beginning,
 10 cent hackers out there that D is a language of the future -- that it 
 HAS a
 future -- at the center of a stable and growing community.  All this feeds 
 into
 the notions that I outlined in my first message.  Design a system -- not 
 just
 part of the language -- to foster growth and stability, and people will 
 search
 YOU out, and not the other way around.  The keys to that system revolves 
 around
 finding what is necessary within the community and then designing toward 
 those
 goals.

 So, with that in mind, let me offer up some ideas that I have been 
 ruminating
 upon.

 First: The Build Mechanism
 I've tried to play around a little with Build, and I think to a certain 
 extent
 it's a fine tool.  What it lacks, I feel is not so much the ability to 
 compile a
 series of programs but to really bring the end product together for users. 
 To
 clarify: what build doesn't really seem to do is build in 
 user-friendliness into
 the libraries.  To a large extent, I think this more the fault of 
 documentation
 than of Build.  In my idea of a build tool, the documentation is far more
 succinct and far more powerful; it leverages the native unicode support of 
 D
 against XML.  Now, I know XML is everyone's favorite language to hate, as 
 it
 quickly becomes quite complicated if not done well, but I feel that by 
 using a
 basic and standardized syntax, D could quickly develop a usable (online)
 documentation system that exists in real-time with the development code 
 itself.
 Allow me to elaborate with the following, very rough example

 ---D source---
 /++doc.xml
 <doc lang="en_us">
 <author name="Danger Duck" date="01.12.07" liscense="GPLv3" />
 <method>
 <param>long sec_uid</param>
 <desc>A fake variable passed to secure this message against flame</desc>
 <return>A <link lib="util.fire.safety">FlameRetardantSuit</link> to 
 protect user
 against singing</return>
 </method>
 <example><![CDATA[[
 {
 Suit s = Suit.getRetardantSuit(my_long_security_id); /* pass in unique 
 id*/
 s.buttonUpItsGonnaGetHotInHere(); /* Lock yourself in the vault */
 s.waitForAllClear(clear_handler); /* Whew!, saved my tail feathers again! 
 */
 s.divest(); /* release the lock */
 }
 ]]>
 </example>
 <tutorial><![CDATA[
 You have to know what you're doing when you use this object.  Put it on 
 too
 soon, and you may overheat and cook your own goose.  Put it on too late, 
 and
 those henpecked farmers may get your gizzard.  As you can see from this 
 example
 <example ref="inline" /> the feathers are really flying.  Use it 
 carefully,
 though, and it'll all be like water off a duck's back.

 I apologize for all the fowl phrases.
 ]]>
 </tutorial>
 </doc>
 <doc lang="fr_fr">
 <method nom_de_poulet="Danger Duck" date="01.12.07" permet="GPLv3">
 <param>long sec_uid</param>
 <usage>Parlez le francais mieux de moi</usage>
 <rentre>Quelquechose de 'honk'</rentre>
 <exemple>
 ..etc., etc., etc., ...
 </doc>
 +/
 public FlameRetardantSuit getFlameRetardantSuit(long sec_uid) {
 ...
 }

 --- end D ---
 As you can see, it's possible to implement documentation at a level that 
 can be
 directly transformed into any number of kinds of documentation.   You 
 could
 publish the API and the examples on the Web; you could publish a library
 reference in PDF; you could distribute a localized tutorial in every 
 language
 imaginable.  The possibilities, frankly, for brining in people form around 
 the
 world are virtually limitless.  I know that this probably seems like way 
 too
 much documentation for a single method, but I think the idea is 
 essentially
 there -- it just has to be mined efffectively.

 Second:
 I've heard back from a few people about having a small core library.  I 
 can
 certainly respect that: coming from Java, I know what it feels like to 
 have a
 glut of options.  On the other hand, one of the undeniable draws for a 
 language
 is a substantial library of well-tested code.  The functionality of a 
 language
 is, in this sense, directly reflected in the composition of its libraries. 
 To
 that end, I would propose a two-tiered solution.  On the first tier, there 
 sits
 two basic libraries: 'lang' and 'sys'.  Unlike Java, which hides much of 
 the
 implementation details of the system, D users should be allowed the 
 freedom to
 deal directly with the hardware and the underlying system when needed. 
 For this
 reason, the sys and the lang packages will supply all of the basic 
 functionality
 needed for D to run in any environment.  This should especially appeal to
 systems programmers and library implementers, as one can hide a good deal 
 of
 existing c code behind some carefully constructed interfaces or superior
 packaging.  The 'lang' package, in particular, needs the 'sys' libs in 
 order to
 deliver all of the low-level coding required by each operating system, 
 thus, I
 believe, releiving even some of the lower details from language 
 implementors.
 It should be the case that these two packages are automatically searched 
 and
 compiled into any running program, though the top level DPATH may only 
 refer to
 '/usr/include/d/', or whatnot.

 The second part of this teir delivers everything else that the core 
 library
 lacks, including complicated IO, data structures, utilities, ui 
 components, and
 parsers.  I've given a rough outline of what the library might looklike 
 below.
 Of course, much of my model liberally samples (i.e. outright steals) from 
 the

 should be
 -- each language should stand on the shoulders of the one that came before 
 it --
 and I think each of those languages are quite good at packaging together
 disparate pieces.  Of course, we wouldn't import from d.xxx -- we can drop 
 the
 'd.' syntax entirely once the compiler supports native library builds; I 
 always
 did resent the whole 'import java....' fiasco.  This seems to be an ok 
 solution
 as long as we make sure that we don't conflict with URL domains in these
 top-level directories.

 d/
 ------ BRL - Basic Runtime Library ------
 lang
 gc
 exception
 thread
 primitives
 array
 bitarray
 string
 box
 hashmap
 compiler
 ..

 sys
 console (for some basic io)
 memory
 call (hiding system calls, I thought)
 lib  (Windows lib, glibc, ... what have you)
 ..

 -------------------------------------------

 ----- ERL - Extended Runtime Library ------

 ext
 c
 stdio
 math
 fenv
 process
 stdarg
 stddef
 stdlib
 string
 time
 ..
 c++
 ..

 data (collections/standard data structures, probably via templates)
 ArrayList
 Stack
 Queue
 LinkedList
 DoublyLinkedList
 CircularlyLinkedList
 BinaryTree
 Map
 ..

 util
 compress (protocols for bzip, gzip, tar etc.)
 logging
 date
 random
 ..

 os (or 'kaos', for nameing conflicts [kernel and o/s] -- hsa mythic 
 overtones)
 posix
 c
 windows
 c
 ..
 com
 ..
 dotnet
 linux
 c
 ..
 kernel (???)
 ..
 userland (???)
 titan
 minix
 ..

 security
 crypt
 md5
 sha1
 ..
 dgp (a port of gnu pgp might be very helpful, if signing mail, for 
 instance)
 invoke (secure calls to the system? 'Titan' might find this useful)
 ssl
 key

 math
 complex
 fourier
 boolean
 ..

 ui
 curses
 thea (D language graphical system based on the qt framework)
 opengl
 window
 ..
 ..

 text
 encoding
 unicode
 ansi
 codepage
 locale
 format
 regex
 parsers
 CVS
 yaml
 yacc (?)
 ..

 sql
 dbi (database interface abstraction)
 vendor (specific vendor APIs)
 slumber (hibernate or ado api?)
 ..

 io  (or 'dio', to avoid any conflicts)
 file
 buffer
 pipe
 stream
 ..

 inet (to deal with local imports like net.chickenplucker.geetar.blah)
 socket
 server
 http
 udp
 ftp
 mail
 encoding
 protocols
 ident
 url
 uri
 ..
 reactor
 svn
 ..

 xml
 parsers
 validators
 xpath
 xslt
 rpc
 soap
 ..

 ..

 ----------------------------------------

 One last thing before I slip off to bed: I really want to rally around an 
 open
 source license for this project, particularly one that strives for 
 complete
 transparency.  Not only does this really promote a sense of sharing and
 community, but I feel that it also gives newcomers and old hackers some 
 ideals
 to really identify with.  To that end I would suggest the GPL as the 
 starting
 point -- possibly even liscenesed under some kind of dual GPL/LGPL 
 liscense.
 This kind of transparency, I feel, really invites people to the table in 
 an
 egalitarian and communal way.  (Not to mention the fact that putting it 
 under
 the GPL opens up the floodworks for linking into other GPL code -- and 
 there's
 tons of it.)

 I'm sure that I've forgotten a few things in all this, and I think that 
 there's
 so much more to say, but I'm tired so I wish you all a fond goodnight and 
 I look
 forward to reading your responses in the morning.

 Quack!
 Gabe
Apr 26 2006
prev sibling next sibling parent Walter Bright <newshound digitalmars.com> writes:
gabe wrote:


 As you can see, it's possible to implement documentation at a level that can be
 directly transformed into any number of kinds of documentation.


I agree. But there is no need to actually write documentation in xml 
format, which is unbelievably painful to use. Writing it in Ddoc format 
is pretty simple, and Ddoc's output can be automatically transformed 
into XML by providing a different set of ddoc macros.
Apr 26 2006
prev sibling next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
gabe wrote:

 One last thing before I slip off to bed: I really want to rally around an open
 source license for this project, particularly one that strives for complete
 transparency.  Not only does this really promote a sense of sharing and
 community, but I feel that it also gives newcomers and old hackers some ideals
 to really identify with.  To that end I would suggest the GPL as the starting
 point -- possibly even liscenesed under some kind of dual GPL/LGPL liscense.
 This kind of transparency, I feel, really invites people to the table in an
 egalitarian and communal way.  (Not to mention the fact that putting it under
 the GPL opens up the floodworks for linking into other GPL code -- and there's
 tons of it.)


The license for Phobos is in one of the following forms:

1) public domain

2)
/*
  *  Copyright (C) 2006 by [your name]
  *  Written by [your name]
  *
  *  This software is provided 'as-is', without any express or implied
  *  warranty. In no event will the authors be held liable for any damages
  *  arising from the use of this software.
  *
  *  Permission is granted to anyone to use this software for any purpose,
  *  including commercial applications, and to alter it and redistribute it
  *  freely, subject to the following restrictions:
  *
  *  o  The origin of this software must not be misrepresented; you must not
  *     claim that you wrote the original software. If you use this software
  *     in a product, an acknowledgment in the product documentation 
would be
  *     appreciated but is not required.
  *  o  Altered source versions must be plainly marked as such, and must not
  *     be misrepresented as being the original software.
  *  o  This notice may not be removed or altered from any source
  *     distribution.
  */

I think that covers it. It's open source, and far less restrictive than 
the GPL.
Apr 26 2006
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Walter Bright wrote:


 The license for Phobos is in one of the following forms:
 
 1) public domain
 
 2)
 /*
  *  Copyright (C) 2006 by [your name]
  *  Written by [your name]
  *
  *  This software is provided 'as-is', without any express or implied
  *  warranty. In no event will the authors be held liable for any damages
  *  arising from the use of this software.
  *
  *  Permission is granted to anyone to use this software for any purpose,
  *  including commercial applications, and to alter it and redistribute it
  *  freely, subject to the following restrictions:
  *
  *  o  The origin of this software must not be misrepresented; you must not
  *     claim that you wrote the original software. If you use this software
  *     in a product, an acknowledgment in the product documentation 
 would be
  *     appreciated but is not required.
  *  o  Altered source versions must be plainly marked as such, and must not
  *     be misrepresented as being the original software.
  *  o  This notice may not be removed or altered from any source
  *     distribution.
  */
 
 I think that covers it. It's open source, and far less restrictive than 
 the GPL.


If you want to make things easier/shorter when talking with Open Source 
guys, this license is commonly known as the "zlib / libpng license"...

http://www.opensource.org/licenses/zlib-license.php


However, for DMD 0.154 it is not entirely true. There are still some
exceptions to this rule, mostly for the old Synesis Software modules:

http://www.prowiki.org/wiki4d/wiki.cgi?PhobosLicenseIssues

As many have pointed out, std.loader and std.recls needs to be fixed.
My own suggestion is to rewrite std.loader, and to drop the std.recls ?

--anders
Apr 27 2006
parent reply jcc7 <jcc7_member pathlink.com> writes:
In article <e2pqob$iba$1 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...

Walter Bright wrote:


 The license for Phobos is in one of the following forms:
 
 1) public domain
 
 2)
 /*
  *  Copyright (C) 2006 by [your name]
  *  Written by [your name]
  *
  *  This software is provided 'as-is', without any express or implied
  *  warranty. In no event will the authors be held liable for any damages
  *  arising from the use of this software.
  *
  *  Permission is granted to anyone to use this software for any purpose,
  *  including commercial applications, and to alter it and redistribute it
  *  freely, subject to the following restrictions:
  *
  *  o  The origin of this software must not be misrepresented; you must not
  *     claim that you wrote the original software. If you use this software
  *     in a product, an acknowledgment in the product documentation 
 would be
  *     appreciated but is not required.
  *  o  Altered source versions must be plainly marked as such, and must not
  *     be misrepresented as being the original software.
  *  o  This notice may not be removed or altered from any source
  *     distribution.
  */
 
 I think that covers it. It's open source, and far less restrictive than 
 the GPL.


If you want to make things easier/shorter when talking with Open Source 
guys, this license is commonly known as the "zlib / libpng license"...

http://www.opensource.org/licenses/zlib-license.php


However, for DMD 0.154 it is not entirely true. There are still some
exceptions to this rule, mostly for the old Synesis Software modules:

http://www.prowiki.org/wiki4d/wiki.cgi?PhobosLicenseIssues

As many have pointed out, std.loader and std.recls needs to be fixed.
My own suggestion is to rewrite std.loader, and to drop the std.recls ?

--anders


I thought Walter had already announced (back in February) that he was going to
remove std.recls.

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/33352

But I guess that hasn't happened yet.

jcc7
Apr 27 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
jcc7 wrote:

 I thought Walter had already announced (back in February) that he was going to
 remove std.recls.
 
 http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/33352
 
 But I guess that hasn't happened yet.


I was going to remove it when Matthew provided a url where I could 
forward interested recls users to. But that hasn't happened. I suppose 
it's time to just remove it anyway.
Apr 27 2006
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Walter Bright wrote:


 I was going to remove it when Matthew provided a url where I could 
 forward interested recls users to. But that hasn't happened. I suppose 
 it's time to just remove it anyway.


I found that recls.org redirected me to
http://synesis.com.au/software/recls/ ?

--anders
Apr 27 2006
parent Walter Bright <newshound digitalmars.com> writes:
Anders F Björklund wrote:

 Walter Bright wrote:
 

 I was going to remove it when Matthew provided a url where I could 
 forward interested recls users to. But that hasn't happened. I suppose 
 it's time to just remove it anyway.


 
 I found that recls.org redirected me to
 http://synesis.com.au/software/recls/ ?


I'll go with that, then.
Apr 27 2006
prev sibling next sibling parent Derek Parnell <derek psych.ward> writes:
On Thu, 27 Apr 2006 06:15:39 +0000 (UTC), gabe wrote:


 First: The Build Mechanism
 I've tried to play around a little with Build, and I think to a certain extent
 it's a fine tool.  


Thanks. You do realize that this tool was not written by, or with the help
(or blessing) of DigitalMars. I wrote it because I was tired of maintaining
makefiles.


 What it lacks, I feel is not so much the ability to compile a
 series of programs but to really bring the end product together for users.


The Build tool has one purpose - to build a target file - either an
executable or library, depending on your needs. It is not designed to
generate documentation or install packages. KISS.


   To
 clarify: what build doesn't really seem to do is build in user-friendliness
into
 the libraries.  To a large extent, I think this more the fault of documentation
 than of Build.


See above. But what do you actually mean by the phrase "build in
user-friendliness into the libraries"? How can a tool like Build improve
the documentation content of the libraries? The formatting of the API
documentation is very flexible and can generate decent docs. 

(However, if Walter does add a method of creating indexes and Table of
Contents inside Ddoc soon, I might just add this to Build.)


  In my idea of a build tool, 


That depends on what you are trying to build.


 the documentation is far more
 succinct and far more powerful; it leverages the native unicode support of D
 against XML.  Now, I know XML is everyone's favorite language to hate, as it
 quickly becomes quite complicated if not done well, but I feel that by using a
 basic and standardized syntax, D could quickly develop a usable (online)
 documentation system that exists in real-time with the development code itself.
 Allow me to elaborate with the following, very rough example


Allow me to Ddoc-ify your example code ...

---D source---

  /**
  $(doc $(lang(en_us),
  $(author $(name Danger Duck), $(date 01.12.07), $(license GPLv3))
    A fake variable passed to secure this message against flame

    params: 
     sec_uid = A security user identifier.

    returns: $(link util.fire.safety, FlameRetardantSuit) to protect user
             against singing

    $(example example1,
      Suit s = Suit.getRetardantSuit(my_long_security_id); /* pass in
unique id*/
      s.buttonUpItsGonnaGetHotInHere(); /* Lock yourself in the vault */
      s.waitForAllClear(clear_handler); /* Whew!, saved my tail feathers
again! */
      s.divest(); /* release the lock */
    )

   $(tutorial
    You have to know what you're doing when you use this object.  Put it on
too soon, and you may overheat and cook your own goose.  Put it on too
late, and those henpecked farmers may get your gizzard.  As you can see
from this $(local example1, example) the feathers are really flying.  Use
it carefully, though, and it'll all be like water off a duck's back.

 I apologize for all the fowl phrases.
    )

  )
**/
--- end D ---


 As you can see, it's possible to implement documentation at a level that can be
 directly transformed into any number of kinds of documentation.


Just as one can do with Ddoc.


   You could
 publish the API and the examples on the Web; you could publish a library
 reference in PDF; you could distribute a localized tutorial in every language
 imaginable.  The possibilities, frankly, for brining in people form around the
 world are virtually limitless.  I know that this probably seems like way too
 much documentation for a single method, but I think the idea is essentially
 there -- it just has to be mined efffectively.


Yeah, like I said. Ddoc is designed with that very functionality in mind.
 

 Second:
 ... I would propose a two-tiered solution ...


I like where that idea is going. 



 One last thing before I slip off to bed: I really want to rally around an open
 source license for this project, particularly one that strives for complete
 transparency. 


The only thing that is not transparent is the DigitalMars compiler
back-end; the part that converts the IL into optimized machine code. And
this is mainly because of historical reasons I believe. Anyone is free to
develop an open source back end if they want a different implementation of
the compiler. However, the language itself is not 'closed' even though the
text of the DigitalMars specification is copyrighted.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
27/04/2006 4:20:33 PM
Apr 26 2006
prev sibling next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
gabe wrote:


 Second:
 I've heard back from a few people about having a small core library.  I can
 certainly respect that: coming from Java, I know what it feels like to have a
 glut of options.  On the other hand, one of the undeniable draws for a language
 is a substantial library of well-tested code.  The functionality of a language
 is, in this sense, directly reflected in the composition of its libraries.  To
 that end, I would propose a two-tiered solution.  On the first tier, there sits
 two basic libraries: 'lang' and 'sys'.  Unlike Java, which hides much of the
 implementation details of the system, D users should be allowed the freedom to
 deal directly with the hardware and the underlying system when needed.  For
this
 reason, the sys and the lang packages will supply all of the basic
functionality
 needed for D to run in any environment.  This should especially appeal to
 systems programmers and library implementers, as one can hide a good deal of
 existing c code behind some carefully constructed interfaces or superior
 packaging.  The 'lang' package, in particular, needs the 'sys' libs in order to
 deliver all of the low-level coding required by each operating system, thus, I
 believe, releiving even some of the lower details from language implementors.


Q: How is this different from how D things currently work ?
We have Phobos/Ares ('lang') calling the C library ('sys')

All that is needed to use C libraries is to write an import
module, for C++ you need to export it as extern "C" {} first.

So I think it already works this way, it's how I am using it.


 It should be the case that these two packages are automatically searched and
 compiled into any running program, though the top level DPATH may only refer to
 '/usr/include/d/', or whatnot.  


The standard install of GDC uses e.g. /usr/include/d/3.3.6,
(where the version signifies the GCC that it was built with)
for including the std Phobos/runtime files from the compiler.

It used to search /usr/include/d as well, for user libraries,
but I think it doesn't anymore (had to add: -I/usr/include/d)
I think /usr/include/d is good, the same as /usr/include/c++

The C library is used automatically, and then it adds: -lphobos
(DMD uses "gcc" to link, while GDC normally uses "gdc" there too)

So both the C and D libraries are searched and included already ?


 The second part of this teir delivers everything else that the core library
 lacks, including complicated IO, data structures, utilities, ui components, and
 parsers.  I've given a rough outline of what the library might looklike below.
 Of course, much of my model liberally samples (i.e. outright steals) from the

 -- each language should stand on the shoulders of the one that came before it
--
 and I think each of those languages are quite good at packaging together
 disparate pieces.  Of course, we wouldn't import from d.xxx -- we can drop the
 'd.' syntax entirely once the compiler supports native library builds; I always
 did resent the whole 'import java....' fiasco.  This seems to be an ok solution
 as long as we make sure that we don't conflict with URL domains in these
 top-level directories.  


Adding all those features to *one* single library / project,
would make it quite heavy and rather big - don't you think ?

But Mango does cover a fair lot of the "server" ones now...
DWT was supposed to cover GUI, but it seems to be in trouble.


 ----- ERL - Extended Runtime Library ------


[...]

 os (or 'kaos', for nameing conflicts [kernel and o/s] -- hsa mythic overtones)
 posix
 c
 windows
 c
 ..
 com
 ..
 dotnet
 linux
 c


GDC is currently divided into Windows and Unix (*not* Posix !),
which I think is an improvement over what DMD has (only linux)

std.windows.*
std.unix.*

std.c.windows.*
std.c.unix.*

The different Unix platforms are available too, mostly empty:
linux/darwin/freebsd/cygwin/aix/solaris, plus any future ones.


 ui 
 curses
 thea (D language graphical system based on the qt framework)
 opengl
 window
 ..
 ..


Another UI framework ? Didn't know there was a working Qt->D wrapper ?
(then again the DIUP port looks promising, for any simple interfaces)


 One last thing before I slip off to bed: I really want to rally around an open
 source license for this project, particularly one that strives for complete
 transparency.  Not only does this really promote a sense of sharing and
 community, but I feel that it also gives newcomers and old hackers some ideals
 to really identify with.  To that end I would suggest the GPL as the starting
 point -- possibly even liscenesed under some kind of dual GPL/LGPL liscense.
 This kind of transparency, I feel, really invites people to the table in an
 egalitarian and communal way.  (Not to mention the fact that putting it under
 the GPL opens up the floodworks for linking into other GPL code -- and there's
 tons of it.)


But many people hate the GPL with a passion... So a common solution is a
dual GPL/proprietary license (like DMD), or a BSD license (like Phobos)

And both Public Domain and LGPL/wxWidgets licenses are used for some big 
D existing projects, too. (e.g. MinWin, wxD) There's lots of options...

--anders
Apr 27 2006
prev sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
gabe wrote:


 In article <e2pgfg$4s3$1 digitaldaemon.com>, nick says...

Sounds to me as though you are really eager to have D1.0 right this
moment and you are frustrated with all the things that aren't working
just the way you like them.


 
 Well, you're only partially right about that.  I do have some
 dissapointment
 that things don't exactly 'work'.  I think that anything that doesn't just
 'work' for people coming to the language (or even working in it for a long
 time), tends to make D look inflexible and amaturish compared to other
 efforts. That is not to say that D is in any way either of those things --
 I think it has the potential to be very robust and quite user-friendly,
 but in order for the language to really succeed, you're going to have to
 convince more than just me. In order to succeed, you're going to have to
 convince all the other beginning, 10 cent hackers out there that D is a
 language of the future -- that it HAS a
 future -- at the center of a stable and growing community.  All this feeds
 into
 the notions that I outlined in my first message.  Design a system -- not
 just part of the language -- to foster growth and stability, and people
 will search
 YOU out, and not the other way around.  The keys to that system revolves
 around finding what is necessary within the community and then designing
 toward those goals.


I wonder why I didn't see this message the first time around... Anyway, I
got my morning coffee now :)

Your thoughts are all sound, but the community IS building what it needs. As

infrastructure at the bottom there is NOT created by the community, but by
the backing corporations. Which is why D still might end up as you
envision, but it will take time :)


 
 So, with that in mind, let me offer up some ideas that I have been
 ruminating upon.
 
 First: The Build Mechanism


Build is an extremely powerful tool that I in general find well documented,
but it is a command line tool, which probably is not whay you have in mind?
But build should be easily usable from an IDE (and I think it is used in
several already).


 
 ---D source---


Please no XML in the source code, it is NOT easily readable (or writable).
As has been said DDoc already fills this space (although it still could be
improved) and it is possible to make additional tools to process the output
into a fullblown Javadoc style documentation, or maybe something even
better. CandyDoc which can be found under the Helix project at DSource is a
starting point for what is possible.


 
 Second:



 ------ BRL - Basic Runtime Library ------
 
 ----- ERL - Extended Runtime Library ------


I like these ideas (it is not as if they haven't been suggested before), but
I agree with Anders in that the BRL part of it is mostly there, he suggests
Phobos, I think Ares got it even clearer, although it is not as complete
yet.

As for the ERL, I think that will be much more difficult to get right,
although it would be nice to have a "standard" that could be shipped with
the compiler. Walter already has suggested to have a standard GUI, and
other packages might follow. I guess if we as a community actually can
agree on a setup, he might include it all.

The reason I think it might be difficult, is because D in itself gives us

because we might care even more about speed, we probably will pick and
choose the right library for us even more than others do, similar to what
happens in the C/C++ world.

Oh, and AFAIK, an effort to make a Qt inspired library in D has just been
started :D Just to give is just a tiny bit more choice ;) Or possibly
because someone got tired of hearing about how good Qt is and why it should
be ported to D...

--
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi
Apr 27 2006
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Lars Ivar Igesund wrote:


 I like these ideas (it is not as if they haven't been suggested before), but
 I agree with Anders in that the BRL part of it is mostly there, he suggests
 Phobos, I think Ares got it even clearer, although it is not as complete
 yet.


Actually I said Phobos/Ares I think ? I'm not sure if there's any reason
to use both at once, I think Ares is a community replacement for Phobos.

There is also "gphobos", the GNU Phobos which differs from the DM Phobos 
in the same way that the GNU D Compiler differs from the DM D Compiler.


 As for the ERL, I think that will be much more difficult to get right,
 although it would be nice to have a "standard" that could be shipped with
 the compiler. Walter already has suggested to have a standard GUI, and
 other packages might follow. I guess if we as a community actually can
 agree on a setup, he might include it all.


I'd rather have the "standard" libraries small and working, than large
and broken, if I had to choose between the lesser of the two evils...

Because you can always add a library later on, but it's *hard* to work
against a broken standard library (like with the recls and phobos bugs)


If it's all supported and tested (like Java - but preferrably open too)
then having a big library is good. If not, I'd prefer the C approach...

i.e. have a small runtime, and add any of the others as you see fit


 The reason I think it might be difficult, is because D in itself gives us

 because we might care even more about speed, we probably will pick and
 choose the right library for us even more than others do, similar to what
 happens in the C/C++ world.


Seeing as how D gives you three string types, I would say you are right.
;-)


 Oh, and AFAIK, an effort to make a Qt inspired library in D has just been
 started :D Just to give is just a tiny bit more choice ;) Or possibly
 because someone got tired of hearing about how good Qt is and why it should
 be ported to D...


There's a lot of nice things done in Qt, only downside is their dual 
license (GPL/commercial) which I find less flexible than the others.

--anders
Apr 27 2006
prev sibling next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Probably the biggest problem you mentioned is the documentation. 
Fortunately, though, we now have Ddoc. I've been converting more of the 
older documentation files over to Ddoc format, and discovered what I 
expected: every one of the module documentation files either:

1) did not mention some of the functions

2) documented functions that did not exist

3) had documentation at odds with the code comments for the same function

Ddoc, while not terribly sophisticated, is good enough to use, and it 
offers an enormous step forward in making it easy to write and keep up 
to date the documentation. It easily cuts the work in half, maybe more, 
and it certainly makes it easy to enforce a common look & feel to the 
documentation.

Anyhow, I hear you. I welcome your help in any way you feel you can best 
contribute.
Apr 26 2006
parent reply Kyle Furlong <kylefurlong gmail.com> writes:
Walter Bright wrote:

 Probably the biggest problem you mentioned is the documentation. 
 Fortunately, though, we now have Ddoc. I've been converting more of the 
 older documentation files over to Ddoc format, and discovered what I 
 expected: every one of the module documentation files either:
 
 1) did not mention some of the functions
 
 2) documented functions that did not exist
 
 3) had documentation at odds with the code comments for the same function
 
 Ddoc, while not terribly sophisticated, is good enough to use, and it 
 offers an enormous step forward in making it easy to write and keep up 
 to date the documentation. It easily cuts the work in half, maybe more, 
 and it certainly makes it easy to enforce a common look & feel to the 
 documentation.
 
 Anyhow, I hear you. I welcome your help in any way you feel you can best 
 contribute.


Really? If this is really true, and you welcome help, what shall we do? 
How is one supposed to help you if you do not have a list of things we 
can help you with?
Apr 27 2006
parent reply Derek Parnell <derek psych.ward> writes:
On Thu, 27 Apr 2006 00:31:12 -0700, Kyle Furlong wrote:


 Walter Bright wrote:

 Probably the biggest problem you mentioned is the documentation. 
 Fortunately, though, we now have Ddoc. I've been converting more of the 
 older documentation files over to Ddoc format, and discovered what I 
 expected: every one of the module documentation files either:
 
 1) did not mention some of the functions
 
 2) documented functions that did not exist
 
 3) had documentation at odds with the code comments for the same function
 
 Ddoc, while not terribly sophisticated, is good enough to use, and it 
 offers an enormous step forward in making it easy to write and keep up 
 to date the documentation. It easily cuts the work in half, maybe more, 
 and it certainly makes it easy to enforce a common look & feel to the 
 documentation.
 
 Anyhow, I hear you. I welcome your help in any way you feel you can best 
 contribute.


 
 Really? If this is really true, and you welcome help, what shall we do? 
 How is one supposed to help you if you do not have a list of things we 
 can help you with?


For example Walter, can I send you Phobos modules with improved
documentation in them and no source code changes? What is the method you
use to accept Phobos source code changes? I presume you do a line-by-line
analysis and manually incorporate those lines you wish to.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
27/04/2006 6:03:13 PM
Apr 27 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Derek Parnell wrote:

 On Thu, 27 Apr 2006 00:31:12 -0700, Kyle Furlong wrote:

 Walter Bright wrote:

 Anyhow, I hear you. I welcome your help in any way you feel you can best 
 contribute.


 Really? If this is really true, and you welcome help, what shall we do? 
 How is one supposed to help you if you do not have a list of things we 
 can help you with?


 
 For example Walter, can I send you Phobos modules with improved
 documentation in them and no source code changes? What is the method you
 use to accept Phobos source code changes? I presume you do a line-by-line
 analysis and manually incorporate those lines you wish to.



On any Phobos changes, yes, I do a line by line check on any changes, 
and do a manual merge.

Two areas that could use big improvements are in the Ddoc comments and 
in the unit tests. For Ddoc in particular, usage examples for every 
function are needed.

For unit tests, enough needs to be there to get 100% coverage as 
verified by the D coverage analyzer. Having 100% coverage means that 
it's much easier to improve the libraries without slipping into reverse.

I know there isn't much glory in either of those two tasks, but Ddoc and 
the D coverage analyzer make them much easier, and they make the 
difference between a professional and an amateur project.
Apr 27 2006
next sibling parent reply "Derek Parnell" <derek psych.ward> writes:
On Thu, 27 Apr 2006 19:22:33 +1000, Walter Bright  
<newshound digitalmars.com> wrote:



 Two areas that could use big improvements are in the Ddoc comments and  
 in the unit tests. For Ddoc in particular, usage examples for every  
 function are needed.

 For unit tests, enough needs to be there to get 100% coverage as  
 verified by the D coverage analyzer. Having 100% coverage means that  
 it's much easier to improve the libraries without slipping into reverse.

 I know there isn't much glory in either of those two tasks, but Ddoc and  
 the D coverage analyzer make them much easier, and they make the  
 difference between a professional and an amateur project.


Ok then! :D

This I can do (and I'm not after the "glory" either). I'll make a start  
tonight and see how we go.

-- 
Derek Parnell
Melbourne, Australia
Apr 27 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Derek Parnell wrote:

 This I can do (and I'm not after the "glory" either). I'll make a start 
 tonight and see how we go.


The std.stream can use some attention. It is unusable without looking at 
the source :-(
Apr 28 2006
parent Derek Parnell <derek psych.ward> writes:
On Fri, 28 Apr 2006 00:35:11 -0700, Walter Bright wrote:


 Derek Parnell wrote:

 This I can do (and I'm not after the "glory" either). I'll make a start 
 tonight and see how we go.


 
 The std.stream can use some attention. It is unusable without looking at 
 the source :-(


Ok. I've already started on std.date so I'll finish that first.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
28/04/2006 5:52:32 PM
Apr 28 2006
prev sibling next sibling parent reply Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:

 Derek Parnell wrote:

 For example Walter, can I send you Phobos modules with improved
 documentation in them and no source code changes? What is the method you
 use to accept Phobos source code changes? I presume you do a line-by-line
 analysis and manually incorporate those lines you wish to.


 
 On any Phobos changes, yes, I do a line by line check on any changes, 
 and do a manual merge.


By this may I assume you use a merge tool?  If not, please permit me to 
plug UltraCompare as the best thing since fuel injection.


Sean
Apr 27 2006
parent Walter Bright <newshound digitalmars.com> writes:
Sean Kelly wrote:

 Walter Bright wrote:

 On any Phobos changes, yes, I do a line by line check on any changes, 
 and do a manual merge.


 
 By this may I assume you use a merge tool?  If not, please permit me to 
 plug UltraCompare as the best thing since fuel injection.


I just use good ol' diff.
Apr 27 2006
prev sibling parent Don Clugston <dac nospam.com.au> writes:
Walter Bright wrote:

 Derek Parnell wrote:

 On Thu, 27 Apr 2006 00:31:12 -0700, Kyle Furlong wrote:

 Walter Bright wrote:

 Anyhow, I hear you. I welcome your help in any way you feel you can 
 best contribute.


 Really? If this is really true, and you welcome help, what shall we 
 do? How is one supposed to help you if you do not have a list of 
 things we can help you with?


 For example Walter, can I send you Phobos modules with improved
 documentation in them and no source code changes? What is the method you
 use to accept Phobos source code changes? I presume you do a line-by-line
 analysis and manually incorporate those lines you wish to.


 
 
 On any Phobos changes, yes, I do a line by line check on any changes, 
 and do a manual merge.
 
 Two areas that could use big improvements are in the Ddoc comments and 
 in the unit tests. For Ddoc in particular, usage examples for every 
 function are needed.
 
 For unit tests, enough needs to be there to get 100% coverage as 
 verified by the D coverage analyzer. Having 100% coverage means that 
 it's much easier to improve the libraries without slipping into reverse.
 
 I know there isn't much glory in either of those two tasks, but Ddoc and 
 the D coverage analyzer make them much easier, and they make the 
 difference between a professional and an amateur project.


While on the subject of code coverage and documentation...
It won't show up as code coverage, but the enum in std.regexp includes 
REstar, REplus, and REquest, which are never used. This makes the code 
harder to understand.
I also note that std.regexp seems to support both greedy and non-greedy 
matches, but this is not documented anywhere.
Apr 28 2006
prev sibling next sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
gabe wrote:


 I've been reading these posts for a while now, and going over the
 documentation, and discovering some of the tools, and a few things have
 jumped out at me about the D language and the D community:


You absolutely has given this thought, but have you tried the language? If
you had participated at least some in the discussions around here, you
would have discovered that unlike Java, D isn't backed by a huge
corporation that wants to take over the world, more like the mad professor
(no insults intended Walter ;) who wants to take over the world.


 
 Arrow One: The Message


You are right, D's message is somewhat unclear, and it has been discussed
whether D should get a strategy for market deployment. Possibly, but D is
still under development, and it turns out it has so much promise that we're
not really sure where it'll end.

Hmm, I guess you really talked about documentation, and it's true, it mostly
sucks. But then it is so much more fun coding D than writing docs for
it! :D


 
 Arrow Two: Liscenses.


Not any issue IMHO, the liscenses are circumventable, most libraries
available open source, we have GDC which is a fully open source compiler,
and almost nothing is licensed in a way that would prevent it from being
used in a commercial projects (which already exists in several locations).


 
 Arrow Third: Solidarity and conformance.


While I'd like coding standards and such, those following D are not
particularly homogenic in their thoughts on the matter. Just try to read a
couple of the project internal style discussions over at DScource. And many
ppl actually don't like such conventions, so restrict too much and you
might push away some of the small group already committed to D.


 
 Exclamation Solutions:
 I would like to get involved in the D community in developing the tools
 that will make D a truly great language. To make that possible, however,
 we need to add a centralizing force and focus to the disparate goals of
 the project. First, we need to design some kind of mission statement --
 something that uniquely defines our goals as a community and as a group of
 programmers devoted to making D a better language for everyone to use.
 Second, we need to decide on some goals -- goals that will help us realize
 our mission by making it easer for people to come to D from other
 languages (or even there first language!). Third, we need to organize
 ourselves into groups that can work on aspects of the mission and can
 communicate easily to one another. This means that we need redundancy in
 projects (so that if someone leaves, someone else can take over),
 democratization across the group (so that API's and tools can have
 community input), and distributied responsibilites for all members (so
 that each person feels that they belong through to the group -- not merely
 because they say they do, but because they have earned the respect and the
 trust of their fellow members). In short, D should be a language where the
 community that bands around it is one of openness, respect, and excited
 collaboration.
 
 I would like to post some more ideas about this, and I'd like to start
 organizing those people who are interested in joining together. I'd like
 to hear back from the community about this. I'd like to hear back from
 people excited about making D the best possible language it can be -- and
 making programming in D an absolute joy.
 
 I look forward to hearing from you!
 _________________
 New to the land of D, but I like the look of the place.
 -Gabe


Similar suggestions has been made before, I think it's 2+ years now since I
made mine. Anyway, I also think it's needed at some point, but doubt it can
be pulled off already now. I wouldn't mind you trying though, but for me to
follow, you would have to show a genuine interest in the language
(preferably by helping out an existing project, and it would be wonderful
if this would actually be documentation.)

It is also fairly common to disclose your real name here, and preferably at
least type of occupation and previous experience. I'd like to know who
drives any car I'm a passenger in.

When that is said, feel free to post any preliminary documents on whatever
subject, I'd very much like to see them.

--
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi
Apr 27 2006
prev sibling parent reply John Demme <me teqdruid.com> writes:
gabe wrote:
[... Lots of stuff cut]

 
 I look forward to hearing from you!
 _________________
 New to the land of D, but I like the look of the place.
 -Gabe


It sounds to me like a project needs to be started with the goal of
producing a packaged D.  One file (with an installer) that includes:
-DMD (or GDC)
-build
-Ares + Mango
-A set of Ddoc macros to get some really nice documentation output
-Really nice looking and complete documentation
-Code examples, along with compilation instructions
-Integration of this software, where ever applicable

I might note that a lot of this stuff already exists, but it needs to be
packaged together!

IMO, Walter does a great job with DMD, but it's only one piece of the
puzzle, and we can't expect him to do much else (DMD alone is more than one
person can handle; good thing Walter's superhuman.)  A community needs to
work on putting together something presentable, that someone new to D can
download, install, and start using quickly.  All of the software included
needs to be independently verified as working, and thus might not be the
latest version, but it needs to work right off the bat.

Walter, if such a project was started, would you grant the project a
redistribution license for DMD?

Does anyone have any suggestions for other D software that should be
included?

~John Demme
Apr 27 2006
parent pragma <pragma_member pathlink.com> writes:
In article <e2r088$2in4$1 digitaldaemon.com>, John Demme says...

gabe wrote:
[... Lots of stuff cut]

 
 I look forward to hearing from you!
 _________________
 New to the land of D, but I like the look of the place.
 -Gabe


It sounds to me like a project needs to be started with the goal of
producing a packaged D.  One file (with an installer) that includes:
-DMD (or GDC)
-build
-Ares + Mango
-A set of Ddoc macros to get some really nice documentation output
-Really nice looking and complete documentation
-Code examples, along with compilation instructions
-Integration of this software, where ever applicable

I might note that a lot of this stuff already exists, but it needs to be
packaged together!


Exactly! Kind of a "D Programmer's Toolkit" or SDK.

If I may make some suggestions for inclusion: 

- Installation features for both Windows and Linux/Unix users.  Perhaps even
provide an .exe or .msi for Windows folks and scripts for both userland and root
installations under *nix.

- Would obviously be lacking an IDE and windowing toolkit once those projects
mature.

Actually, if Walter just included build with his DMD distros, that would be a
huge step forward.  On a new system it's already the third thing I download
right after DMD and the DMC backend.

- EricAnderton at yahoo
Apr 27 2006