www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - standardization of D

reply "Ameer Armaly" <ameer_armaly hotmail.com> writes:
Hi all. There are a few things which have been bothering me as of late, and 
I want your opinions on them to know whether or not I'm jumping at shadows. 
For starters, we all have a common goal of making D as widely used as 
possible since we all love the language, otherwise we probably wouldn't be 
here. At the same time, there are a few factors which as I see it make the 
adoption of D much more difficult and need to be addressed if we intend to 
succeed:
1. 1.0 doesn't appear to be any special sort of marker with regard to the 
standard; we have not only CTFE but mixins added post-1.0, along with 
numerous changes to the _standard_library. I understand the compiler can be 
made to strictly conform to the 1.0 spec, but the fact still remains it 
seems very ad hoc. What ought to happen IMO is that we first call a review 
of the language spec where everyone sends in any complaints they have and 
they must be clearly addressed to everyone's satisfaction, or at least to 
the degree that's possible. Then, the spec ought to be frozen for a while, 
and we work strictly on the standard library, which I'll address later. 
Then, the whole D language, including standard library, ought to be frozen 
for several years to let it proliferate throughout the technical community; 
an experimental compiler can of course undergo development, but clearly 
marked as such and _separate_ from the stable compiler.
2. We have two competing standard libraries; this is nowhere near good. 
Phobos is basically built on C wherever possible and sort of thrown 
together, and Tango reminds me of Java with a class for everything and then 
some. For the standard's sake (and consequent adoption), D needs one 
accepted standard library. The current state makes that difficult because 
Walter is forced to hand-manage both the compiler and library. What ought to 
happen IMO is that Walter should delegate day to day library management to a 
trusted associate who will occasionally inform Walter of the latest 
developments; Walter makes the final call, and life goes on.
So to conclude, these are issues that have been sort of addressed at various 
times in other issues, but never to a point that accomplished the intended 
goal. The D community is growing; there are going to be a lot of new people 
that look at it now and say "Huh? Say again?" Maybe we ought to step back 
and forget the years we've had to become comfortable with D and analyze it 
from a potential user's point of view in order to make adoption easier.
Thoughts?
Apr 04 2007
next sibling parent reply Dan <murpsoft hotmail.com> writes:
Ameer Armaly Wrote:


 1. 1.0 doesn't appear to be any special sort of marker with regard to the 
 standard; we have not only CTFE but mixins added post-1.0, along with 
 numerous changes to the _standard_library. I understand the compiler can be 
 made to strictly conform to the 1.0 spec, 


Exactly, so you can continue to develop for the 1.0 spec, and that code will
work, to my understanding, as advertised.


but the fact still remains it 
 seems very ad hoc. 



 Then, the whole D language, including standard library, ought to be frozen 
 for several years to let it proliferate throughout the technical community; 


I totally disagree with this statement.  We have a frozen implementation of D
1.0, and a frozen spec for the language of D 1.0.  That can proliferate as much
as people like.  I feel that as long as future 1.x compilers support 1.0 code,
people can write 1.0 code and it will work universally on people's compilers.


 an experimental compiler can of course undergo development, but clearly 
 marked as such and _separate_ from the stable compiler.
 2. We have two competing standard libraries; this is nowhere near good. 


I feel that this is perfectly fine.  People can develop a program using either
library and I can compile it on my system.  10 libraries would be retarded, and
very bad.  2 really isn't.


 Phobos is basically built on C wherever possible and sort of thrown 
 together, and Tango reminds me of Java with a class for everything and then 
 some. For the standard's sake (and consequent adoption), D needs one 
 accepted standard library. 


I disagree, in fact being able to plug in a library according to your
programming philosophy will probably allow us to develop superior programs.


 The current state makes that difficult because 
 Walter is forced to hand-manage both the compiler and library. What ought to 
 happen IMO is that Walter should delegate day to day library management to a 
 trusted associate who will occasionally inform Walter of the latest 
 developments; Walter makes the final call, and life goes on.


My understanding is that Walter develops and maintains D and D language spec;
and that he wrote the original Phobos.  I think someone else is maintaining
Phobos under that system, while yet someone else is maintaining Tango and
releasing without constant verification from Walter - and with Walter's
occasional contributions.


 So to conclude, these are issues that have been sort of addressed at various 
 times in other issues, but never to a point that accomplished the intended 
 goal. The D community is growing; there are going to be a lot of new people 
 that look at it now and say "Huh? Say again?" Maybe we ought to step back 
 and forget the years we've had to become comfortable with D and analyze it 
 from a potential user's point of view in order to make adoption easier.


D is constantly being nitpicked on this forum - and the fact that it hasn't
been feature frozen has allowed it to continue to be nitpicked and evolve into
a better language.  I feel that the current process Walter is employing is
almost even more important than the language itself; as clearly C++ and C
stagnated leading for a need to replace those languages.

Sincerely,
Dan
Apr 04 2007
parent "Ameer Armaly" <ameer_armaly hotmail.com> writes:
"Dan" <murpsoft hotmail.com> wrote in message 
news:ev1ch5$t6u$1 digitalmars.com...

 Ameer Armaly Wrote:


 1. 1.0 doesn't appear to be any special sort of marker with regard to the
 standard; we have not only CTFE but mixins added post-1.0, along with
 numerous changes to the _standard_library. I understand the compiler can 
 be
 made to strictly conform to the 1.0 spec,


 Exactly, so you can continue to develop for the 1.0 spec, and that code 
 will work, to my understanding, as advertised.


but the fact still remains it
 seems very ad hoc.



 Then, the whole D language, including standard library, ought to be 
 frozen
 for several years to let it proliferate throughout the technical 
 community;


 I totally disagree with this statement.  We have a frozen implementation 
 of D 1.0, and a frozen spec for the language of D 1.0.  That can 
 proliferate as much as people like.  I feel that as long as future 1.x 
 compilers support 1.0 code, people can write 1.0 code and it will work 
 universally on people's compilers.


Perhaps, but (1) the standard libraries aren't standard, and (2) it looks 
less intuitive to someone who takes a glance at the language for the first 
time.

 an experimental compiler can of course undergo development, but clearly
 marked as such and _separate_ from the stable compiler.
 2. We have two competing standard libraries; this is nowhere near good.


 I feel that this is perfectly fine.  People can develop a program using 
 either library and I can compile it on my system.  10 libraries would be 
 retarded, and very bad.  2 really isn't.


 Phobos is basically built on C wherever possible and sort of thrown
 together, and Tango reminds me of Java with a class for everything and 
 then
 some. For the standard's sake (and consequent adoption), D needs one
 accepted standard library.


 I disagree, in fact being able to plug in a library according to your 
 programming philosophy will probably allow us to develop superior 
 programs.


Maybe, but everyone here can testify to the cumbersome nature of plugging in 
any one library; it's not quite as easy as all that. Besides, look at C; it 
has one standard library but you could build anything you want on top of it. 
The idea is not so much that one implimentation be better, but that one be 
constant; many programs have to write standard C or posix functions because 
they aren't present on certain operating systems. Besides, if one program 
had to be compiled with one lib but everything else with another, you have 
to go through that whole process unnecessarily.

 The current state makes that difficult because
 Walter is forced to hand-manage both the compiler and library. What ought 
 to
 happen IMO is that Walter should delegate day to day library management 
 to a
 trusted associate who will occasionally inform Walter of the latest
 developments; Walter makes the final call, and life goes on.


 My understanding is that Walter develops and maintains D and D language 
 spec; and that he wrote the original Phobos.  I think someone else is 
 maintaining Phobos under that system, while yet someone else is 
 maintaining Tango and releasing without constant verification from 
 Walter - and with Walter's occasional contributions.


 So to conclude, these are issues that have been sort of addressed at 
 various
 times in other issues, but never to a point that accomplished the 
 intended
 goal. The D community is growing; there are going to be a lot of new 
 people
 that look at it now and say "Huh? Say again?" Maybe we ought to step back
 and forget the years we've had to become comfortable with D and analyze 
 it
 from a potential user's point of view in order to make adoption easier.


 D is constantly being nitpicked on this forum - and the fact that it 
 hasn't been feature frozen has allowed it to continue to be nitpicked and 
 evolve into a better language.  I feel that the current process Walter is 
 employing is almost even more important than the language itself; as 
 clearly C++ and C stagnated leading for a need to replace those languages.

 Sincerely,
 Dan
Apr 04 2007
prev sibling next sibling parent reply Sean Kelly <sean f4.ca> writes:
Ameer Armaly wrote:

 Hi all. There are a few things which have been bothering me as of late, and 
 I want your opinions on them to know whether or not I'm jumping at shadows. 
 For starters, we all have a common goal of making D as widely used as 
 possible since we all love the language, otherwise we probably wouldn't be 
 here. At the same time, there are a few factors which as I see it make the 
 adoption of D much more difficult and need to be addressed if we intend to 
 succeed:
 1. 1.0 doesn't appear to be any special sort of marker with regard to the 
 standard; we have not only CTFE but mixins added post-1.0, along with 
 numerous changes to the _standard_library. I understand the compiler can be 
 made to strictly conform to the 1.0 spec, but the fact still remains it 
 seems very ad hoc. What ought to happen IMO is that we first call a review 
 of the language spec where everyone sends in any complaints they have and 
 they must be clearly addressed to everyone's satisfaction, or at least to 
 the degree that's possible. Then, the spec ought to be frozen for a while, 
 and we work strictly on the standard library, which I'll address later. 
 Then, the whole D language, including standard library, ought to be frozen 
 for several years to let it proliferate throughout the technical community; 
 an experimental compiler can of course undergo development, but clearly 
 marked as such and _separate_ from the stable compiler.


The idea of a separate compiler for experimental features has come up in 
the past and I think it's a good one.  But if it's easier for Walter to 
maintain a single compiler and provide a feature switch then that seems 
fine as well.  Also, other review models have been suggested, with the 
Python approach suggested as one alternative IIRC.  This is ultimately 
up to Walter however, and the method he feels would be most productive 
or beneficial to language development.  I can't claim to have any strong 
feelings here one way or the other.


 2. We have two competing standard libraries; this is nowhere near good. 
 Phobos is basically built on C wherever possible and sort of thrown 
 together, and Tango reminds me of Java with a class for everything and then 
 some. For the standard's sake (and consequent adoption), D needs one 
 accepted standard library.


For what it's worth, Tango is only positioned as a "standard library" 
because it includes compiler runtime features (out of necessity), and 
because of its scope.  It was never intended to compete directly with 
Phobos.  To some, this distinction may be simply a matter of semantics, 
but I do feel it's important to point this out since it was never our 
intention to confuse things.  That said, if a choice truly had to be 
made between Phobos, Tango, etc, for a "D standard library" then that 
choice will be made by the community simply by virtue of whatever 
library each individual decides to use.  I don't know that an arbitrary 
decision would carry much weight here.


 The current state makes that difficult because
 Walter is forced to hand-manage both the compiler and library.


I think there is some benefit to Walter maintaining Phobos, as it allows 
new compiler releases to include library code demonstrating or 
supporting the use of new language features.  This is something that 
would be more difficult to achieve if the library work were handled by 
someone else.  That isn't to say that there are no alternatives to this, 
but it bears mentioning.


 What ought to
 happen IMO is that Walter should delegate day to day library management to a 
 trusted associate who will occasionally inform Walter of the latest 
 developments; Walter makes the final call, and life goes on.


There is also the issue of maintaining the compiler runtime code vs. the 
remainder of the library code.  Whatever happens at the user level, the 
compiler writer will want to maintain any runtime code that compiler 
requires.


 So to conclude, these are issues that have been sort of addressed at various 
 times in other issues, but never to a point that accomplished the intended 
 goal. The D community is growing; there are going to be a lot of new people 
 that look at it now and say "Huh? Say again?" Maybe we ought to step back 
 and forget the years we've had to become comfortable with D and analyze it 
 from a potential user's point of view in order to make adoption easier.
 Thoughts? 


Only that D is still a young language and that I feel things will sort 
themselves out in time.  Until then, we can simply do our best to 
clearly answer any questions posed by new users and to avoid overt 
conflict in public discussions.  After all, the way we interact with one 
another reflects upon D as a whole, and if we can't make sense of what's 
going on then how is a new user supposed to? :-)


Sean
Apr 04 2007
parent BCS <BCS pathlink.com> writes:
Sean Kelly wrote:


 The idea of a separate compiler for experimental features has come up in 
 the past and I think it's a good one.  But if it's easier for Walter to 
 maintain a single compiler and provide a feature switch then that seems 
 fine as well.  Also, other review models have been suggested, with the 
 Python approach suggested as one alternative IIRC.  This is ultimately 
 up to Walter however, and the method he feels would be most productive 
 or beneficial to language development.  I can't claim to have any strong 
 feelings here one way or the other.


This could be rolled into the "there is really only one compiler" 
problem and start up a totally new compiler development project. I 
actually am working on this (slowly, vary vary slowly, the lexer works 
but I'm having some UTF-16 convention problems). However my project only 
  addresses the experimental compiler issue because I'm not intending 
mine to be used outside of experimental testing.
Apr 05 2007
prev sibling next sibling parent reply janderson <askme me.com> writes:
Although you raise some good points I can't agree here.  I think D still 
has a few more years development until we get to that stage.  People are 
only just starting to use it for real.  We should have the flexibility 
to fix their issues as they arise rather then setting it in stone at the 
moment.  I see 1.0 as kinda like a speedbump to stability.  The more we 
go over the more set in stone it'll get.  I think this will be a much 
more valid argument at 2.0 and even more so at 3.0.

-Joel

Ameer Armaly wrote:

 Hi all. There are a few things which have been bothering me as of late, and 
 I want your opinions on them to know whether or not I'm jumping at shadows. 
 For starters, we all have a common goal of making D as widely used as 
 possible since we all love the language, otherwise we probably wouldn't be 
 here. At the same time, there are a few factors which as I see it make the 
 adoption of D much more difficult and need to be addressed if we intend to 
 succeed:
 1. 1.0 doesn't appear to be any special sort of marker with regard to the 
 standard; we have not only CTFE but mixins added post-1.0, along with 
 numerous changes to the _standard_library. I understand the compiler can be 
 made to strictly conform to the 1.0 spec, but the fact still remains it 
 seems very ad hoc. What ought to happen IMO is that we first call a review 
 of the language spec where everyone sends in any complaints they have and 
 they must be clearly addressed to everyone's satisfaction, or at least to 
 the degree that's possible. Then, the spec ought to be frozen for a while, 
 and we work strictly on the standard library, which I'll address later. 
 Then, the whole D language, including standard library, ought to be frozen 
 for several years to let it proliferate throughout the technical community; 
 an experimental compiler can of course undergo development, but clearly 
 marked as such and _separate_ from the stable compiler.
 2. We have two competing standard libraries; this is nowhere near good. 
 Phobos is basically built on C wherever possible and sort of thrown 
 together, and Tango reminds me of Java with a class for everything and then 
 some. For the standard's sake (and consequent adoption), D needs one 
 accepted standard library. The current state makes that difficult because 
 Walter is forced to hand-manage both the compiler and library. What ought to 
 happen IMO is that Walter should delegate day to day library management to a 
 trusted associate who will occasionally inform Walter of the latest 
 developments; Walter makes the final call, and life goes on.
 So to conclude, these are issues that have been sort of addressed at various 
 times in other issues, but never to a point that accomplished the intended 
 goal. The D community is growing; there are going to be a lot of new people 
 that look at it now and say "Huh? Say again?" Maybe we ought to step back 
 and forget the years we've had to become comfortable with D and analyze it 
 from a potential user's point of view in order to make adoption easier.
 Thoughts?
Apr 04 2007
parent reply "Ameer Armaly" <ameer_armaly hotmail.com> writes:
"janderson" <askme me.com> wrote in message 
news:ev1u1d$1q81$1 digitalmars.com...

 Although you raise some good points I can't agree here.  I think D still 
 has a few more years development until we get to that stage.  People are 
 only just starting to use it for real.  We should have the flexibility to 
 fix their issues as they arise rather then setting it in stone at the 
 moment.  I see 1.0 as kinda like a speedbump to stability.  The more we go 
 over the more set in stone it'll get.  I think this will be a much more 
 valid argument at 2.0 and even more so at 3.0.


It seems then that we interpret 1.0 in different ways; my first thought was 
that it was going to be a setup (language, compiler, libs) that people could 
just pick up and run with. But apparently not...

 -Joel

 Ameer Armaly wrote:

 Hi all. There are a few things which have been bothering me as of late, 
 and I want your opinions on them to know whether or not I'm jumping at 
 shadows. For starters, we all have a common goal of making D as widely 
 used as possible since we all love the language, otherwise we probably 
 wouldn't be here. At the same time, there are a few factors which as I 
 see it make the adoption of D much more difficult and need to be 
 addressed if we intend to succeed:
 1. 1.0 doesn't appear to be any special sort of marker with regard to the 
 standard; we have not only CTFE but mixins added post-1.0, along with 
 numerous changes to the _standard_library. I understand the compiler can 
 be made to strictly conform to the 1.0 spec, but the fact still remains 
 it seems very ad hoc. What ought to happen IMO is that we first call a 
 review of the language spec where everyone sends in any complaints they 
 have and they must be clearly addressed to everyone's satisfaction, or at 
 least to the degree that's possible. Then, the spec ought to be frozen 
 for a while, and we work strictly on the standard library, which I'll 
 address later. Then, the whole D language, including standard library, 
 ought to be frozen for several years to let it proliferate throughout the 
 technical community; an experimental compiler can of course undergo 
 development, but clearly marked as such and _separate_ from the stable 
 compiler.
 2. We have two competing standard libraries; this is nowhere near good. 
 Phobos is basically built on C wherever possible and sort of thrown 
 together, and Tango reminds me of Java with a class for everything and 
 then some. For the standard's sake (and consequent adoption), D needs one 
 accepted standard library. The current state makes that difficult because 
 Walter is forced to hand-manage both the compiler and library. What ought 
 to happen IMO is that Walter should delegate day to day library 
 management to a trusted associate who will occasionally inform Walter of 
 the latest developments; Walter makes the final call, and life goes on.
 So to conclude, these are issues that have been sort of addressed at 
 various times in other issues, but never to a point that accomplished the 
 intended goal. The D community is growing; there are going to be a lot of 
 new people that look at it now and say "Huh? Say again?" Maybe we ought 
 to step back and forget the years we've had to become comfortable with D 
 and analyze it from a potential user's point of view in order to make 
 adoption easier.
 Thoughts?
Apr 05 2007
next sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
Ameer Armaly wrote:


 
 "janderson" <askme me.com> wrote in message
 news:ev1u1d$1q81$1 digitalmars.com...

 Although you raise some good points I can't agree here.  I think D still
 has a few more years development until we get to that stage.  People are
 only just starting to use it for real.  We should have the flexibility to
 fix their issues as they arise rather then setting it in stone at the
 moment.  I see 1.0 as kinda like a speedbump to stability.  The more we
 go
 over the more set in stone it'll get.  I think this will be a much more
 valid argument at 2.0 and even more so at 3.0.


 It seems then that we interpret 1.0 in different ways; my first thought
 was that it was going to be a setup (language, compiler, libs) that people
 could just pick up and run with. But apparently not...


That would have been ideal, but if that really was the case, 1.0 was rushed
out way too early :)

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango
Apr 05 2007
prev sibling parent janderson <askme me.com> writes:
Ameer Armaly wrote:

 "janderson" <askme me.com> wrote in message 
 news:ev1u1d$1q81$1 digitalmars.com...

 Although you raise some good points I can't agree here.  I think D still 
 has a few more years development until we get to that stage.  People are 
 only just starting to use it for real.  We should have the flexibility to 
 fix their issues as they arise rather then setting it in stone at the 
 moment.  I see 1.0 as kinda like a speedbump to stability.  The more we go 
 over the more set in stone it'll get.  I think this will be a much more 
 valid argument at 2.0 and even more so at 3.0.


 It seems then that we interpret 1.0 in different ways; my first thought was 
 that it was going to be a setup (language, compiler, libs) that people could 
 just pick up and run with. But apparently not...

 -Joel




My view is that this is our first trial at having a stabilized version. 
  Kinda like a trial run.  1.0 spec is set in stone, bugs are being 
fixed.    2.0 will be more rigid and so on.

-Joel
Apr 05 2007
prev sibling next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Ameer Armaly wrote:


 2. We have two competing standard libraries; this is nowhere near good. 


Yeah, I find that it's kinda funny that we have gone from:

int main(char[][] args)
{
     printf("hello world\n");
     return 0;
}

in the original D introduction and samples to the current:

version (Tango)
import tango.io.Console;
else // Phobos
import std.stdio;

void main()
{
     version (Tango)
     Cout ("Hello, World!").newline;
     else // Phobos
     writefln("Hello, World!");
}

And then there are all these new "D++" additions in progress
that I haven't quite understood yet. Like 4 languages in one :-)

--anders
Apr 05 2007
parent "Ameer Armaly" <ameer_armaly hotmail.com> writes:
"Anders F Björklund" <afb algonet.se> wrote in message 
news:ev2ang$2i85$1 digitalmars.com...

 Ameer Armaly wrote:


 2. We have two competing standard libraries; this is nowhere near good.


 Yeah, I find that it's kinda funny that we have gone from:

 int main(char[][] args)
 {
     printf("hello world\n");
     return 0;
 }

 in the original D introduction and samples to the current:

 version (Tango)
 import tango.io.Console;
 else // Phobos
 import std.stdio;

 void main()
 {
     version (Tango)
     Cout ("Hello, World!").newline;
     else // Phobos
     writefln("Hello, World!");
 }

 And then there are all these new "D++" additions in progress
 that I haven't quite understood yet. Like 4 languages in one :-)


It's just not healthy for adoption's sake; if some big company comes along, 
falls in love with the language itself, then takes a look at the library 
situation I doubt they would be impressed.

 --anders
Apr 05 2007
prev sibling next sibling parent reply "David B. Held" <dheld codelogicconsulting.com> writes:
Ameer Armaly wrote:

 Hi all. There are a few things which have been bothering me as of late, and 
 I want your opinions on them to know whether or not I'm jumping at shadows. 
 For starters, we all have a common goal of making D as widely used as 
 possible since we all love the language, otherwise we probably wouldn't be 
 here. At the same time, there are a few factors which as I see it make the 
 adoption of D much more difficult and need to be addressed if we intend to 
 succeed:
 [...]


I think one thing to keep in mind is that the 1.0 release was basically 
a gift to the user community to lend D that air of authenticity that 
business folks need to let their people use a new toy.  In reality, 
there are so many radical features being considered for D that it's 
really comparable to C++ in its CFront stage rather than the ARM, let 
alone, ANSI stage.  On the one hand, D needs users to push the language 
to expose its weaknesses.  On the other hand, D needs the flexibility to 
break some stuff to add compelling new features.  It's a tricky business 
bootstrapping a new language, and only people who can tolerate life on 
the bleeding edge survive in this kind of space.

D does indeed need a fair bit of time before it becomes sufficiently 
stable to consider something like standardization.  Even choosing a 
standard library would be premature, given that D has nothing like the 
STL yet, though something is planned.  And having a wealth of choices 
isn't a bad thing.  If functionality grossly overlapped, that would be 
one thing.  But by providing libraries with different design 
philosophies to appeal to different user segments, D can ease the 
transition for more programmers.  If anything, now is the time to think 
hard about what you think a language should have, and make a strong case 
for your favorite features.  There's no guarantee your feature will get 
implemented, but look how hard it is to get something added to a 
language as big and mature as C++...

Dave
Apr 05 2007
next sibling parent reply janderson <askme me.com> writes:
David B. Held wrote:

 Ameer Armaly wrote:

 Hi all. There are a few things which have been bothering me as of 
 late, and I want your opinions on them to know whether or not I'm 
 jumping at shadows. For starters, we all have a common goal of making 
 D as widely used as possible since we all love the language, otherwise 
 we probably wouldn't be here. At the same time, there are a few 
 factors which as I see it make the adoption of D much more difficult 
 and need to be addressed if we intend to succeed:
 [...]


 
 I think one thing to keep in mind is that the 1.0 release was basically 
 a gift to the user community to lend D that air of authenticity that 
 business folks need to let their people use a new toy.  In reality, 
 there are so many radical features being considered for D that it's 
 really comparable to C++ in its CFront stage rather than the ARM, let 
 alone, ANSI stage.  On the one hand, D needs users to push the language 
 to expose its weaknesses.  On the other hand, D needs the flexibility to 
 break some stuff to add compelling new features.  It's a tricky business 
 bootstrapping a new language, and only people who can tolerate life on 
 the bleeding edge survive in this kind of space.
 
 D does indeed need a fair bit of time before it becomes sufficiently 
 stable to consider something like standardization.  Even choosing a 
 standard library would be premature, given that D has nothing like the 
 STL yet, though something is planned.  And having a wealth of choices 
 isn't a bad thing.  If functionality grossly overlapped, that would be 
 one thing.  But by providing libraries with different design 
 philosophies to appeal to different user segments, D can ease the 
 transition for more programmers.  If anything, now is the time to think 
 hard about what you think a language should have, and make a strong case 
 for your favorite features.  There's no guarantee your feature will get 
 implemented, but look how hard it is to get something added to a 
 language as big and mature as C++...
 
 Dave


I couldn't have put it better!
Apr 05 2007
parent janderson <askme me.com> writes:
janderson wrote:

 David B. Held wrote:

 Ameer Armaly wrote:

 Hi all. There are a few things which have been bothering me as of 
 late, and I want your opinions on them to know whether or not I'm 
 jumping at shadows. For starters, we all have a common goal of making 
 D as widely used as possible since we all love the language, 
 otherwise we probably wouldn't be here. At the same time, there are a 
 few factors which as I see it make the adoption of D much more 
 difficult and need to be addressed if we intend to succeed:
 [...]


 I think one thing to keep in mind is that the 1.0 release was 
 basically a gift to the user community to lend D that air of 
 authenticity that business folks need to let their people use a new 
 toy.  In reality, there are so many radical features being considered 
 for D that it's really comparable to C++ in its CFront stage rather 
 than the ARM, let alone, ANSI stage.  On the one hand, D needs users 
 to push the language to expose its weaknesses.  On the other hand, D 
 needs the flexibility to break some stuff to add compelling new 
 features.  It's a tricky business bootstrapping a new language, and 
 only people who can tolerate life on the bleeding edge survive in this 
 kind of space.

 D does indeed need a fair bit of time before it becomes sufficiently 
 stable to consider something like standardization.  Even choosing a 
 standard library would be premature, given that D has nothing like the 
 STL yet, though something is planned.  And having a wealth of choices 
 isn't a bad thing.  If functionality grossly overlapped, that would be 
 one thing.  But by providing libraries with different design 
 philosophies to appeal to different user segments, D can ease the 
 transition for more programmers.  If anything, now is the time to 
 think hard about what you think a language should have, and make a 
 strong case for your favorite features.  There's no guarantee your 
 feature will get implemented, but look how hard it is to get something 
 added to a language as big and mature as C++...

 Dave


 
 I couldn't have put it better!


Academic wise 1.0 is a good thing because you want people to be able to 
compile and run your algorithms.  For instance, my pre 1v thesis source 
code will no-longer compile because a couple of the D libraries I was 
using broke.  Luckily I have a version of the compiler that did work 
however foolishly I forgot to mention which version.

-Joel
Apr 08 2007
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
David B. Held wrote:

 Ameer Armaly wrote:

 Hi all. There are a few things which have been bothering me as of 
 late, and I want your opinions on them to know whether or not I'm 
 jumping at shadows. For starters, we all have a common goal of making 
 D as widely used as possible since we all love the language, otherwise 
 we probably wouldn't be here. At the same time, there are a few 
 factors which as I see it make the adoption of D much more difficult 
 and need to be addressed if we intend to succeed:
 [...]


 
 I think one thing to keep in mind is that the 1.0 release was basically 
 a gift to the user community to lend D that air of authenticity that 
 business folks need to let their people use a new toy.  In reality, 
 there are so many radical features being considered for D that it's 
 really comparable to C++ in its CFront stage rather than the ARM, let 
 alone, ANSI stage.  On the one hand, D needs users to push the language 
 to expose its weaknesses.  On the other hand, D needs the flexibility to 
 break some stuff to add compelling new features.  It's a tricky business 
 bootstrapping a new language, and only people who can tolerate life on 
 the bleeding edge survive in this kind of space.
 


Indeed. Aside publicity/marketing, does D 1.0 even matter at all? By 
"matter", I mean, who of the D developers (even if just hobbying around) 
use, work with, or generally care about D 1.0 instead of the current D? 
Likely few or none, especially with the amazing new features added, and 
even more are planned to come.


-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Apr 07 2007
parent reply Clay Smith <clayasaurus gmail.com> writes:
I'm just a hobbyer, but I care about the D v1.0 version switch. 

This switch makes it so any compiler after version 1.0 can compile my programs,
and anyone who writes a D 1.0 compatible compiler can also compile my programs.
D 1.0 is a nice 'target' that doesn't move. To be able to ever stabilize, a
language needs such a target or it will forever be left for the bleeding edgers.

~ Clay

Bruno Medeiros Wrote:

 
 Indeed. Aside publicity/marketing, does D 1.0 even matter at all? By 
 "matter", I mean, who of the D developers (even if just hobbying around) 
 use, work with, or generally care about D 1.0 instead of the current D? 
 Likely few or none, especially with the amazing new features added, and 
 even more are planned to come.
 
 
 -- 
 Bruno Medeiros - MSc in CS/E student
 http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Apr 07 2007
next sibling parent reply "Peter C. Chapin" <pchapin sover.net> writes:
Clay Smith <clayasaurus gmail.com> wrote in
news:ev9lsv$tn3$1 digitalmars.com: 


 I'm just a hobbyer, but I care about the D v1.0 version switch. 
 
 This switch makes it so any compiler after version 1.0 can compile my
 programs, and anyone who writes a D 1.0 compatible compiler can also
 compile my programs. D 1.0 is a nice 'target' that doesn't move. To be
 able to ever stabilize, a language needs such a target or it will
 forever be left for the bleeding edgers. 


I agree with this. The existence of v1.0 means that one can write 
software that compiles with the 1.0 version of the language and publish 
it as such knowing that everyone else should understand what that means. 
Of course such software won't be able to use any new features added to 
the language later; that is understood. But in some cases the new 
features are unnecessary to get the job done well so they don't really 
matter.

Of course this would be a bigger deal if there were a variety of 
competing D implementations. Otherwise writing "D v1.0 conformant 
software" is mostly just a formality.

I'm also a hobbiest when it comes to D, but I basically just watched the 
language until 1.0 was released. Now I'm playing with 1.0 and I probably 
won't upgrade myself for a while. If I tried to upgrade all the software 
I use whenever a new version was released I'd spend all of my time 
upgrading software and very little time actually doing anything. 
Consequently I appreciate the stability implied by the 1.0 release.

Ideally once 1.0 was released there should have been a fork in the 
release schedule for D. Bug fixes to 1.0 could be provided separately 
from language enhancements leading toward 2.0 (or whatever). That way 
people interested in coding to the 1.0 "standard" could get a fixed 
compiler without the "clutter" of new features. Do the latest compilers 
have a v1.0 compatibility switch? That would also be a reasonable 
solution.

Peter

P.S. Is there some way to find out the current version of DMD from the 
DigitalMars web page, short of downloading and unpacking the thing? I 
would have expected to find the latest release version number easily 
visible, say on the download page, but there is nothing (unless I'm 
being very dense and just missing it).
Apr 08 2007
next sibling parent Mike Parker <aldacron71 yahoo.com> writes:
Peter C. Chapin wrote:


 compiler without the "clutter" of new features. Do the latest compilers 
 have a v1.0 compatibility switch? That would also be a reasonable 
 solution.


-v1


 
 Peter
 
 P.S. Is there some way to find out the current version of DMD from the 
 DigitalMars web page, short of downloading and unpacking the thing? I 
 would have expected to find the latest release version number easily 
 visible, say on the download page, but there is nothing (unless I'm 
 being very dense and just missing it).


http://www.digitalmars.com/d/changelog.html

Current version is always at the top.
Apr 08 2007
prev sibling parent reply "David B. Held" <dheld codelogicconsulting.com> writes:
Peter C. Chapin wrote:

 [...]
 Ideally once 1.0 was released there should have been a fork in the 
 release schedule for D. Bug fixes to 1.0 could be provided separately 
 from language enhancements leading toward 2.0 (or whatever). That way 
 people interested in coding to the 1.0 "standard" could get a fixed 
 compiler without the "clutter" of new features.
 [...]


This is a pretty important point, and more people should complain about 
this.  It does dilute the utility of having a 1.0 release.

Dave
Apr 08 2007
next sibling parent reply "Peter C. Chapin" <pchapin sover.net> writes:
"David B. Held" <dheld codelogicconsulting.com> wrote in
news:evbaso$2jlr$1 digitalmars.com: 


 Ideally once 1.0 was released there should have been a fork in the 
 release schedule for D. Bug fixes to 1.0 could be provided separately
 from language enhancements leading toward 2.0 (or whatever). That way
 people interested in coding to the 1.0 "standard" could get a fixed 
 compiler without the "clutter" of new features.


 
 This is a pretty important point, and more people should complain
 about this.  It does dilute the utility of having a 1.0 release.


Perhaps the v1 switch mentioned in another post addresses this. I
imagine that v1 does not turn on old bugs. Is the latest documentation
clear about what features are in version one and what features have been
added or changed since? 

Perhaps it's time for me to upgrade. :-) It looks like there have been
quite a few bug fixes. 

Peter
Apr 09 2007
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Peter C. Chapin wrote:

 "David B. Held" <dheld codelogicconsulting.com> wrote in
 news:evbaso$2jlr$1 digitalmars.com: 
 

 Ideally once 1.0 was released there should have been a fork in the 
 release schedule for D. Bug fixes to 1.0 could be provided separately
 from language enhancements leading toward 2.0 (or whatever). That way
 people interested in coding to the 1.0 "standard" could get a fixed 
 compiler without the "clutter" of new features.


 This is a pretty important point, and more people should complain
 about this.  It does dilute the utility of having a 1.0 release.


 
 Perhaps the v1 switch mentioned in another post addresses this. I
 imagine that v1 does not turn on old bugs. Is the latest documentation
 clear about what features are in version one and what features have been
 added or changed since? 
 
 Perhaps it's time for me to upgrade. :-) It looks like there have been
 quite a few bug fixes. 
 
 Peter


As far as I understand it, throwing -v1 disables any features that would
change the meaning of your code, and changes the GC back to its v1.0
behaviour.

However, the caveat here is that it does *not* disable features that
don't change the meaning of your code.  For instance, compile-time
function evaluation was added post-1.0, but is not affected by -v1.  The
reasoning behind this is that CTFE allows you to use non-constant
expressions where you previously couldn't.  Ergo, if your code was
written for v1.0, then it couldn't have had any of these expressions,
thus it doesn't change anything.

Or something like that :)  However, I do think that the D docs should
explicitly mark things that have changed since 1.0, possibly even adding
a strict version of -v1 that completely disallows new features so that
people can use the latest compilers to write v1.0-compatible code (and
actually make sure that it will work!).

	-- Daniel

-- 
int getRandomNumber()
{
    return 4; // chosen by fair dice roll.
              // guaranteed to be random.
}

http://xkcd.com/

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D
i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/
Apr 09 2007
parent "Peter C. Chapin" <pchapin sover.net> writes:
Daniel Keep <daniel.keep.lists gmail.com> wrote in news:evd7k4$1759$1
 digitalmars.com:


 However, the caveat here is that it does *not* disable features that
 don't change the meaning of your code.  For instance, compile-time
 function evaluation was added post-1.0, but is not affected by -v1.  The
 reasoning behind this is that CTFE allows you to use non-constant
 expressions where you previously couldn't.  Ergo, if your code was
 written for v1.0, then it couldn't have had any of these expressions,
 thus it doesn't change anything.


Hmm. That's great for existing 1.0 code that is compiled with the newer 
compiler but, as you point out, not so good for people developing new code 
and who wish to conform to the 1.0 definition of the language. I wouldn't 
want the compiler to accept a feature that was post-1.0 that I accidently 
used.

Peter
Apr 09 2007
prev sibling parent Georg Wrede <georg nospam.org> writes:
David B. Held wrote:

 Peter C. Chapin wrote:
 

 [...]
 Ideally once 1.0 was released there should have been a fork in the 
 release schedule for D. Bug fixes to 1.0 could be provided separately 
 from language enhancements leading toward 2.0 (or whatever). That way 
 people interested in coding to the 1.0 "standard" could get a fixed 
 compiler without the "clutter" of new features.


 
 This is a pretty important point, and more people should complain about 
 this.  It does dilute the utility of having a 1.0 release.


There should also be a clear separation in the documentation!!

The D documentation doesn't seem to care what things are 1.0 and what 
"post-1.0". Imagine a programming team trying to conform to 1.0. While 
the compiler can of course barf on too-new things, the programmers have 
a hard time learning what is and what isn't 1.0.

Of course, we could deliver two separate html trees with DMD, but 
obviously the bloat is unacceptable.

Therefore, IMHO, the second-best would be to have the 1.0 html as a 
separate zip, downloadable from DM, -- and adequately advertise it on 
the site.


To help the programming teams in not reading the wrong version (1.0 vs. 
the current), the downloadable 1.0 should have a pale yellow background 
color, as in old paper. Then, e.g. somebody just quickly glancing at a 
colleagues screen (say, to help him understand something), it would 
stand clearly out whether we are looking at 1.0 or the current doc.

All it takes is to change dmd/html/d/style.css on the third line from

   background: white;

to

   background: #ffffc0;

and zip the 1.0 html to the server.


Oh, and of course the *current* doc shoud mention the 1.0 docs being 
available.

---

I wanted to keep this *simple enough to actually become reality now*, 
given Walter's limited time. Obviously a better solution (and one that 
we'll eventually need) would be to have the background with a pale 
yellow D-1.0 watermark-like text, but first things first!
Apr 09 2007
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Clay Smith wrote:

 I'm just a hobbyer, but I care about the D v1.0 version switch. 
 
 This switch makes it so any compiler after version 1.0 can compile my
programs, and anyone who writes a D 1.0 compatible compiler can also compile my
programs. D 1.0 is a nice 'target' that doesn't move. To be able to ever
stabilize, a language needs such a target or it will forever be left for the
bleeding edgers.
 
 ~ Clay
 
 Bruno Medeiros Wrote:

 Indeed. Aside publicity/marketing, does D 1.0 even matter at all? By 
 "matter", I mean, who of the D developers (even if just hobbying around) 
 use, work with, or generally care about D 1.0 instead of the current D? 
 Likely few or none, especially with the amazing new features added, and 
 even more are planned to come.


 -- 
 Bruno Medeiros - MSc in CS/E student
 http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D


 


Yes, I know what the switch allows, but I'm wondering who is actually 
using it.

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Apr 09 2007
parent torhu <fake address.dude> writes:
Bruno Medeiros wrote:
<snip>

 Bruno Medeiros Wrote:

 Indeed. Aside publicity/marketing, does D 1.0 even matter at all? By 
 "matter", I mean, who of the D developers (even if just hobbying around) 
 use, work with, or generally care about D 1.0 instead of the current D? 
 Likely few or none, especially with the amazing new features added, and 
 even more are planned to come.






<snip>

 Yes, I know what the switch allows, but I'm wondering who is actually 
 using it.
 


I have a dwt app that uses it, and the dallegro project uses it too. 
It's mostly a C binding.  I guess one problem is that it makes it more 
complicated for users of dallegro to use backwards compatibility 
breaking features.  They would have to compile the dallegro files 
separately from files that use post-1.0-only features.  So I guess a 
'D_1_0' version ID would be useful.  Or some other system that allows 
libraries to adjust to being built both with and without -v1.  Then the 
compatibility issue could be handled in a way that's transparent to the 
user.

I haven't looked into both DMD and GDC's versions of std.compiler, so I 
don't know how far that would take you.  And then there's Tango.  But 
this should really be part of the compiler, not of the library.
Apr 09 2007
prev sibling next sibling parent reply Clay Smith <clayasaurus gmail.com> writes:
Here are my thoughts:

1) Have two separate compilers, once based on D 1.0 that will 
concentrate on stability, and another one post D 1.0 based on the 
'kitchen sink' of endless features that D seems to accumulate :-P I'm 
actually hoping that somewhere along the line, keywords and features 
will stop being added, once the language is 'good' enough. If we keep on 
adding features forever, we'll get to the same 'different islands of 
programming' problem that C++ has, where only some programmers can use 
some features while other programmers use other features, in fact I'd 
say we have this with templates/mixins now (some folks think it adds to 
much complexity for what its worth), and then you have the difficulty of 
writing a D compiler from scratch.

2) Library issue: Two separate libraries are a pain for users. Maybe the 
D compiler can be bundled with both, with batch/shell script of compiler 
option to switch in between these libraries.

3) Misuse of manpower:

In theory, it would be _nice_ if all the GUI dudes worked on the same 
GUI, and all the standard library dudes worked on the same library. 
Maybe there can be some way to encourage this.


Ameer Armaly wrote:

 Hi all. There are a few things which have been bothering me as of late, and 
 I want your opinions on them to know whether or not I'm jumping at shadows. 
 For starters, we all have a common goal of making D as widely used as 
 possible since we all love the language, otherwise we probably wouldn't be 
 here. At the same time, there are a few factors which as I see it make the 
 adoption of D much more difficult and need to be addressed if we intend to 
 succeed:
 1. 1.0 doesn't appear to be any special sort of marker with regard to the 
 standard; we have not only CTFE but mixins added post-1.0, along with 
 numerous changes to the _standard_library. I understand the compiler can be 
 made to strictly conform to the 1.0 spec, but the fact still remains it 
 seems very ad hoc. What ought to happen IMO is that we first call a review 
 of the language spec where everyone sends in any complaints they have and 
 they must be clearly addressed to everyone's satisfaction, or at least to 
 the degree that's possible. Then, the spec ought to be frozen for a while, 
 and we work strictly on the standard library, which I'll address later. 
 Then, the whole D language, including standard library, ought to be frozen 
 for several years to let it proliferate throughout the technical community; 
 an experimental compiler can of course undergo development, but clearly 
 marked as such and _separate_ from the stable compiler.
 2. We have two competing standard libraries; this is nowhere near good. 
 Phobos is basically built on C wherever possible and sort of thrown 
 together, and Tango reminds me of Java with a class for everything and then 
 some. For the standard's sake (and consequent adoption), D needs one 
 accepted standard library. The current state makes that difficult because 
 Walter is forced to hand-manage both the compiler and library. What ought to 
 happen IMO is that Walter should delegate day to day library management to a 
 trusted associate who will occasionally inform Walter of the latest 
 developments; Walter makes the final call, and life goes on.
 So to conclude, these are issues that have been sort of addressed at various 
 times in other issues, but never to a point that accomplished the intended 
 goal. The D community is growing; there are going to be a lot of new people 
 that look at it now and say "Huh? Say again?" Maybe we ought to step back 
 and forget the years we've had to become comfortable with D and analyze it 
 from a potential user's point of view in order to make adoption easier.
 Thoughts?
Apr 05 2007
parent Pragma <ericanderton yahoo.removeme.com> writes:
Clay Smith wrote:

 Here are my thoughts:


[snip]

 3) Misuse of manpower:
 
 In theory, it would be _nice_ if all the GUI dudes worked on the same 
 GUI, and all the standard library dudes worked on the same library. 
 Maybe there can be some way to encourage this.


Agreed.  We need a collaborative effort on the same scale as (or larger than)
Tango for a good GUI lib for D.

If you look at the GUI matrix on the Wiki, the situation is pretty gruesome. 
Each lib has some of the picture: native 
widget support, cross-platform, release status, wraps a well-known library,
etc.  But none have the complete picture.

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

In a perfect world, we'd have a complete GL-based library (for portability and
performance) that has common widgets that 
look good, has easy to use layout engines, meshes perfectly with the host
desktop (clipboard, D&D, etc), and provides an 
API that is ideal for hacking together new controls.

- EricAnderton at yahoo
Apr 05 2007
prev sibling next sibling parent reply Dan <murpsoft hotmail.com> writes:
 "Anders F Björklund" <afb algonet.se> wrote in message 

 Yeah, I find that it's kinda funny that we have gone from:

 int main(char[][] args)
 {
     printf("hello world\n");
     return 0;
 }

 in the original D introduction and samples to the current:

 version (Tango)
 import tango.io.Console;
 else // Phobos
 import std.stdio;

 void main()
 {
     version (Tango)
     Cout ("Hello, World!").newline;
     else // Phobos
     writefln("Hello, World!");
 }




Wow!  That's god-awful!  I just write:

int main(){ printf("Hello World!\n"); return 0; }

It compiles, for everyone.  Those people who use Tango, write their programs
only for Tango, they don't version every last fucking call off.  That would be
retarded - obviously.

With libraries, the concept is that you pick one, and compile with it.  Job
finished.  

The fact that D has more than one means you *get* to pick one.
The fact that D doesn't have tons, means you can reasonably keep both the
libraries on your computer in case a program you download uses one or the
other.  

Unless you're going to cry about 30Mb?  I can give you $0.15.

Going on about how D is unstable and so bad for commercial development because
it has two libraries that are both evolving...

Oh, and PS: There *IS* a feature freeze at 1.0.

D 1.0 code will compile on everyone's post 1.0 compilers.  You write for the
1.0 spec, your program will work just as it did when D 1.0 was first released. 
What's the name of that compiler flag?
Apr 05 2007
next sibling parent reply =?windows-1252?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Dan wrote:


 Wow!  That's god-awful!  I just write:
 
 int main(){ printf("Hello World!\n"); return 0; }
 
 It compiles, for everyone. 


Sure, this has worked for years - no argument there.
(besides the missing import for "printf", of course)


 Those people who use Tango, write their programs only for Tango, they don't
version every last fucking call off.  That would be retarded - obviously.
 
 With libraries, the concept is that you pick one, and compile with it.  Job
finished.  


This was just for the discussion, and not literally
(even if some libraries do support both at once...)

And it was just two calls :-)
--anders
Apr 05 2007
parent reply Dan <murpsoft hotmail.com> writes:
Anders F Björklund Wrote:


 Dan wrote:
 

 Wow!  That's god-awful!  I just write:
 
 int main(){ printf("Hello World!\n"); return 0; }
 
 It compiles, for everyone. 


 
 Sure, this has worked for years - no argument there.
 (besides the missing import for "printf", of course)


I think printf doesn't actually need to be imported.  I use it all the time, I
think without?


 This was just for the discussion, and not literally
 (even if some libraries do support both at once...)
 
 And it was just two calls :-)
 --anders


True.  

Sorry, reading my words I came accross harsh.  I had a funny smile on my face
when I said it.  : p

You guys were starting to make it sound like D was going monkey business; when
it's got a perfectly stable 1.0 and a pair of solid libraries that can be used
today and the source for them will be there indefinitely (SVN revision system)

The 'new version control system' via SVN is to branch off stable versions, and
keep the development version in trunk - unlike the Linux kernel.  

Arguably, the SVN model is better than the Linux model because the Linux model
(freeze, now go, freeze, now go) stifles development, is inflexible, and
unnaturally arbitrary.  The only advantage I see with the Linux model is it
forces you to eliminate all known bugs for each cycle.

Just my three cents (inflation, not value added)
Apr 05 2007
parent =?windows-1252?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Dan wrote:


 Sure, this has worked for years - no argument there.
 (besides the missing import for "printf", of course)


 
 I think printf doesn't actually need to be imported.  I use it all the time, I
think without?


That's a bug ;-)

http://www.digitalmars.com/d/archives/digitalmars/D/bugs/5838.html


 And it was just two calls :-)


 
 True.  
 
 Sorry, reading my words I came accross harsh.  I had a funny smile on my face
when I said it.  : p


Glad to hear that, you did sound a bit upset about something there.


 You guys were starting to make it sound like D was going monkey business; when
it's got a perfectly stable 1.0 and a pair of solid libraries that can be used
today and the source for them will be there indefinitely (SVN revision system)


Actually I wasn't talking about the compiler or library versions.

I was thinking about that there are three or four ways to write
D programs; as slightly disguised C, with Phobos, with Tango -
and this new self-modifying compile-time meta-language D thing
that I'm not yet grasping but I'm sure it will be very nice :-)

And I didn't mean this was an all *bad* thing, on the contrary.
Being a multiparadigm language, I'd pretty much expect as much ?

--anders
Apr 05 2007
prev sibling parent Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Dan wrote:

 "Anders F Björklund" <afb algonet.se> wrote in message 

 Yeah, I find that it's kinda funny that we have gone from:

 int main(char[][] args)
 {
     printf("hello world\n");
     return 0;
 }

 in the original D introduction and samples to the current:

 version (Tango)
 import tango.io.Console;
 else // Phobos
 import std.stdio;

 void main()
 {
     version (Tango)
     Cout ("Hello, World!").newline;
     else // Phobos
     writefln("Hello, World!");
 }




 
 Wow!  That's god-awful!  I just write:
 
 int main(){ printf("Hello World!\n"); return 0; }
 
 It compiles, for everyone.  Those people who use Tango, write their programs
only for Tango, they don't version every last fucking call off.  That would be
retarded - obviously.


I can confirm this, for myself anyhow.  Although sometimes I do add a line like:
version (Tango) {} else { static assert (false, "Tango required."); }

To the tops of main modules.  Juuuuust in case.


 With libraries, the concept is that you pick one, and compile with it.  Job
finished.  
 
 The fact that D has more than one means you *get* to pick one.
 The fact that D doesn't have tons, means you can reasonably keep both the
libraries on your computer in case a program you download uses one or the
other.  


For one, I'm /glad/ to see two choices.  Diversity spawns (hopefully sporting) 
competition, and competition (usually) breeds innovation.  Plus, Phobos and
Tango lean 
toward different programming styles.  Phobos is very imperative-paradigm
dominated, while 
Tango makes extensive use of OO-paradigm designs.  If someone almost never uses
OO 
programming, then Phobos plus a third-party library or two is a fine way to go.
 If -- 
like me -- they tend to use an awful lot of objects, then Tango makes a nice
initial 
framework.

There are other such comparisons that can be made.


 Unless you're going to cry about 30Mb?  I can give you $0.15.
 
 Going on about how D is unstable and so bad for commercial development because
it has two libraries that are both evolving...
 
 Oh, and PS: There *IS* a feature freeze at 1.0.
 
 D 1.0 code will compile on everyone's post 1.0 compilers.  You write for the
1.0 spec, your program will work just as it did when D 1.0 was first released. 
What's the name of that compiler flag?


That switch would be '-v1' although I didn't see it anywhere in the on-site
documentation. 
  Had to spawn a console and run dmd to check.

-- Chris Nicholson-Sauls
Apr 05 2007
prev sibling parent Derek Parnell <derek psych.ward> writes:
On Wed, 4 Apr 2007 18:24:51 -0400, Ameer Armaly wrote:


 2. We have two competing standard libraries; ...


Do we? I agree we have two competing libraries in as much as they nominally
try to cover the same problem space (with overlapping areas), but is Tango
really the "standard"? That is to say, are the Tango developers attempting
to have it shipped with *every* D compiler? I'm sure that they would like
it to be, but I don't think that they are trying for that.

To me, Phobos is the standard library because it is shipped as a matter of
course (plus is hardcoded into DMD). This is not to say that it is a good
library; I think it really needs *lots* of improvement, but it is the one
that you get when you get a D compiler.

Now maybe if Walter endorsed Tango and also packaged it with DMD we could
say we had competing standards, but ...

-- 
Derek Parnell
Melbourne, Australia
"Justice for David Hicks!"
skype: derek.j.parnell
Apr 05 2007