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

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

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.

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

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

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!

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

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

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

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.