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
didn't work for s!#& when it first came out -- it was clunky, slow, and
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. 

#1) Have you used it? #2) How could it be made better? 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. 

#1) Have you used it? #2) How could it be made better? 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
 didn't work for s!#& when it first came out -- it was clunky, slow, and
 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 Java and C# library implementations. This is the way I feel that it 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
next sibling parent "Alberto Simon" <lugaidster gmail.com> writes:
I would be glad to help with everything you mentioned. I come from a C# 
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 without giving up power and speed, like C# (or any other .NET 
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 Java and C# library implementations. This is the way I feel that it 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. 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.
 
 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鰎klund 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
 Java and C# library implementations.  This is the way I feel that it 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.  

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 I said in my last post about Java (which applies to C# too), the 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 many more possibilities than VM based languages such as Java and C#, and 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
 many more possibilities than VM based languages such as Java and C#, and
 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.

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.

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