Charlie Patterson wrote:
> "Walter" <newshound@digitalmars.com> wrote in message news:d04p7a$550$1@digitaldaemon.com...
> 
>>I've found myself wondering over the last few months what "1.0" actually is.
>>Since D will undergo continuous improvement regardless, why don't we just
>>drive a stake in the ground and call what we have "1.0"?
> 
> 
> If you have a big enough helper base, I'd say you need to treat it like any other product and make sure the whole package is ready.  I get the impression that this still has the feel of a hobby project which means the team will get around to specs, better tutorials and bug fixes when they feel like it.  It's a fun stage, but I don't think it will work in the commercial/professional world.
> 
> You have to go from a project to a product.  I'm not a product manager, but I think a 'product' must assess what a customer needs to really feel comfortable with choosing D.  The language itself is probably only half of it.  I think the product will then include
> 
> * Is attitude correct?
> 
>     * Stop the moving target, or at least fake it.
>         People don't like incomplete things.  Make it stationary and live with it.  (See roadmap.)
> 
>     * got to make people feel supported, not like they are following a temperamental hobbyist.
> 
>         * promise yourselves bugs will be fixed in an almost instant manner
> 
>         * create a newsgroup for support instead of feature debate
> 
>         * make sure you are ready to make real-world trade-offs
>             see .Net below for example
> 
> * 'marketing' materials
> 
>     * clean up language comparison on D site
> 
>     * add to site a little; make friendlier
> 
>     * a confident roadmap
>         features for 1.0, in stone
>         features for 1.1, in stone, Fall 05
>         features for 2.0, fixed but appendable, 2006
>         (again, this should increase other's confidence)
> 
> * documentation
> 
>     * a complete spec
>         no one is going to believe this is open (especially not slashdot) until the spec is complete
> 
>     * a complete reference manual
>         you have most of this on the site. get it cleaned and bound?
> 
>     * a complete programmer's manual
>         keep it simple and non-didactic.  maybe keep it brief for programmers who know C already.  maybe even for those who know C++ or Java. A more thorough manual can probably be put off until next year.  still make it a pdf and get it bound with the reference.
> 
>     * more tutorials
>         especially ones written solving problems that the authors were originally thinking of when they designed certain features.
> 
> * D
>     no known bugs for 1.0
> 
> * a great library
>     I think this should be most of the focus at this point.  I haven't looked at phobos or dtl or whatever, but I think a major point for Java is the promise that there is one main library with all you'll need to get started.  Even though there were many mistakes in Date, AWT, etc.  And even though any one with experience must roll their eyes at such a promise of "one and only," this promise was huge to acceptance IMO.  (And it is frustrating to work in C or Linux and have too many, similar choices of lib and none seem to become a standard.)
>     The promise of backward-compatibility with C libs is huge, but not enough.
>     Is the Java lib worth copying and only fixing the problems?  This would probably provide comfort for lots of programmers.
>     To combine the value of Java's inclusive libraries with C++'s generic programming, you could create the ultimate container classes and let the group fight it out for a month to get the spec perfect.  Anyone have ideas on how other toolkits fell short in design (not just completeness)?  Now is the time to fix that.
>     Anyway, the lib should include most of all the components that the original Java or .Net did.
>     I think the world is still waiting on a wonderful GUI library.  The same mistakes keep getting repeated.  It would be wonderful if D had it's own amazing AWT with delegates, true objects but only when sensible, easy parameterization, etc.  I have lots of thoughts in this area.
> 
> * does it work with .NET?
>     Some may have ideological reasons against it, but this would be huge, also.  It is the big "silver bullet" right now.  .Net has figured out that it is all about libraries nowadays and you can use any lang to connect to their libs.  So you both leverage all that programmer knowledge and you fit in with the latest direction.  (I don't know .NET myself.)
> 
> Feel free to modify the list.  Discuss.  (-:

Thought provoking!

The other day I was pondering over, _how_ would D really beat enough corn stalks to stake out a significant patch on the field.

A parallel that came to mind was that between Linux and Windows. The W crowd have a fixed set of programmers, all "just trying to get the task at hand finished before Frday". The L crowd don't mind how much thinking or typing (er, usually together called "programming") it takes, as long as the end result is something you dare to show the community with your own name. (Or handle.)

Standard issue today in Open Source (OS) development is having a place in an existing infrastructure of Fast and Serious multi-multi-programmer environment. Bug routing facilities, source code repositories, mailing lists with fine-grain sections, ad-hoc-like on-going regrouping of human resources, well divided task sections (like Documentation, Testing, Conceptualising, Project Management, Code Writing, Install Package Management, Platrofm Issues, PR-activities, etc.) All of these are taken care of in the infrastructure.

Today, we have dsource, Digital Mars D documentation pages, this newsgroup, an IRC channel, and a few other things. But they're all separate islands.

I know that Walter wants (and should) keep the back-end Proprietary. No problem. But everything else should be handled like OS does. With all facilities taken maximum benefit from.

---

I just installed Fedora Core 3. While I was somewhat disimpressed with the initial user experience, I have to admit, both FC, Gnome, and KDE-apps have made serious technical advancements since the last free RH release.

That made me feel sorry for Bill Gates. He goes on linearly (or might I venture to say, logarithmically), while the opponents go O(squared), if not even O(exponential). 5 years from now, and he'll have a heck of a time convincing everyone of the Emperor's Clothes. (Heck, even Apple, the epitome of Closed Source, lock-in, patronising, and customer hoarding -- gave up by Os X!)

Using that metaphor, C++ is like an aircraft carrier. Of course you can shoot dead an entire nation with it. But times change. Today, the words are Agility, Rate of Development, ability to Answer to Today's Demands, and, last but not least -- a dedicated community! With these, we ought to fly circles around C++. And not even need a staff of 2000 just to get from Washington DC to New York.

Another thought: what if we adopt some Open Source startegies to improve the rate of advancement?

My dream would be that we use _all_ methods available, to speed up D development. Including documentation, libraries, suggestions to Phobos, package management and distribution, -- everything.

----

I know Walter's too busy (and dammit, _should_ be too busy) to set all this up, so we need somebody else to put up The Authoritative Development Environment (a la Sourceforge, etc.), with Walter's blessing, and _under_his_command_. ((( Jan Knepper, are you listening?? You might use the thing for a lot of good for yourself, too! )))

For all I know, this could even be an Invitation Only Site. But that's not for me to decide.

bamb00 wrote:
>>Is it a commercially viable language yet? IMO it is not.
>>
>>I think 1.0 should be whenever it is.
> 
> 
> Well put.
> 
> 
>>Any ideas on criteria?
> 
> 
> I think DStress has setup a good 'score board'.  I like  your idea on
> getting people that aren't fans of the language, maybe time to setup a
> 'hostile focus group' :).
> 

I think the biggest advantage/burden of D is that is doesn't not link to  C++ very well. The problem being that, say you want to use a lib in C++ (like Qt) to make a GUI, you are going to have to make C bindings for it and then D'atize it again :-/

Also, you can't use D on the current game consoles (Xbox, PS/2), becaus e the dev kits all use c++. (please correct me if wrong)

The people who depend heavily on c++ libs (like Qt), are those who we arn't going to be able to convert to D. Unless, of course, there is a mass re-write of c++ applications to D.

"Carlos Santander B." <csantander619@gmail.com> wrote in message news:d058mm$ndf$2@digitaldaemon.com...
> Matthew wrote:
>>
>> I agree that the book's release and 1.0 coinciding would be nice, but it's unlikely that the book'll be in the shops before Nov/Dec. Maybe if 1.0 is out mid-year, the pre-release book extract articles can be tied in with it, and in that way the book'd coincide with D 1.1, which'll be a large bug fix improvement of 1.0?
>>
>> Or something like that ...
>>
>>
>>
>
> I agree that 1.0 should wait for the book, but I think bug fixing should be a 1.0 goal and not 1.1.

Of course. I simply meant that 1.1 will inevitably be a response to all the things that crop up as a consequence of 1.0. We cannot anticipate everything. ;)

"clayasaurus" <clayasaurus@gmail.com> wrote in message news:42262A7A.1080606@gmail.com...
> bamb00 wrote:
>>>Is it a commercially viable language yet? IMO it is not.
>>>
>>>I think 1.0 should be whenever it is.
>>
>>
>> Well put.
>>
>>
>>>Any ideas on criteria?
>>
>>
>> I think DStress has setup a good 'score board'.  I like  your idea on
>> getting people that aren't fans of the language, maybe time to setup
>> a
>> 'hostile focus group' :).
>>
>
> I think the biggest advantage/burden of D is that is doesn't not link to C++ very well. The problem being that, say you want to use a lib in C++ (like Qt) to make a GUI, you are going to have to make C bindings for it and then D'atize it again :-/
>
> Also, you can't use D on the current game consoles (Xbox, PS/2), becaus e the dev kits all use c++. (please correct me if wrong)
>
> The people who depend heavily on c++ libs (like Qt), are those who we arn't going to be able to convert to D. Unless, of course, there is a mass re-write of c++ applications to D.

Hmm. For any readers of Imperfect C++'s chapter 8, Objects Across Borders, you'll be familiar with my invention of Portable Vtables. I've thought for a while about prodding Walter to see if we can have something along these lines built into D, so it'd be a lot easier than it is in C++. Then we can directly talk between the two languages in a binary-compatible form.

Walter, you read those chapters - at least I hope you did - while reviewing the book. Do you think it'd be easy to adapt D, e.g. via a 'pinterface' keyword?

Matthew wrote:
> "Linguo" <linguo@simpsons.invalid> wrote in message
> news:d04vu4$dvk$1@digitaldaemon.com...
> 
>>clayasaurus wrote:
>>
>>>Then again, theoretically, the sooner D goes out the door, the better
>>>chance it may have to gain a foothold on the other c++ improvements
>>>(C#, Java), unless you think those languages arn't competitive to D
>>>and cater to different markets. (D seems to be for low level stuff,
>>>and Java C# high level GUI type stuff).
>>
>>Then again, theoretically, the sooner D goes out of the door, the
>>better chance it may have to gain a foothold on the other C++
>>improvements (C# and Java), unless you think those languages aren't
>>competitive with D and cater for different markets.  (D seems to be
>>for low-level stuff, and Java and C# for high-level GUI-type stuff.)
>>
>>
>>>If I were W, I would set a 1.0 date for D and release it with the
>>>book so that you will have the time to critically analize D and iron
>>>it out into a smooth machine, before the c++ programmer's can get
>>>ahold of it, critically anylize it, and try to dismiss it for (insert
>>>random drawback here).
>>
>>If I were W, I would set a 1.0 date for D and release it with the
>>book, so that I would have the time to critically analyse D and iron
>>it out into a smooth machine, before the C++ programmers can get hold
>>of it, critically analyse it, and try to dismiss it for (insert random
>>drawback here).
> 
> 
> I agree that the book's release and 1.0 coinciding would be nice, but it's unlikely that the book'll be in the shops before Nov/Dec. Maybe if 1.0 is out mid-year, the pre-release book extract articles can be tied in with it, and in that way the book'd coincide with D 1.1, which'll be a large bug fix improvement of 1.0?

Good point. With the bosses it's Kommon Noledge to never use a 1.0 anyway.

I am a graduate student of Mechanical engineering, I wanted to use D in doing high performance dynamic optimization and for implementing real time simulators for feedback controllers (Matlab is > 1000 times slower than real time!).

After learning Java and C# (and Matlab of course) I hate touching C or C++ But D came to me as a very pleasant surprise; it was love at first sight.

Anyway, I am not very good at using debuggers or even understand the source
of D front end etc. My programs in D crashed too often due to bugs in my code.
I wish, I could get a 'D' IDE with built in debugger, that works on windows.
I wish, phobos be as extensive as java api, with at least one standard GUI api.

I know, I may sound funny or silly for other expert programmers, but atleast for me, the current state of D is not readily usable.

Anyway, I am not blaming anyone, its just, you know .... a little disappointment that the language you love does not have all the things you wanted.

I know, it will take time, and for now, I have to be content with some other language.

Anyway, I really enjoyed whatever coding I did in D.

>> The questin is, what are you guys waiting for?

Well, I am waiting for a complete language, like array literal expressions, mixins, etc etc. extensive API with at least one GUI, with DTL distributed along with D compiler. Well again, I know, it will take time ..... D 1.0 .... D 2.0 ...

I understand, Digitalmars is no Microsoft or no Sun. I guess I have to check back after a long vacation from this ng.

Best Wishes and
Mighty kudos for Walter and all others involved
sai

"Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:d05a7k$pl7$2@digitaldaemon.com...
> Walter, you read those chapters - at least I hope you did - while reviewing the book. Do you think it'd be easy to adapt D, e.g. via a 'pinterface' keyword?

D can hook directly to C++ vtables, as long as the C++ class uses single
inheritance. It becomes a COM interface. Don't actually need to worry about
AddRef() and Release().

That said, I think the yoogest (too borrow from Trump) problem in interfacing with C++ is C++'s memory allocation strategies. A lot of those C++ libraries have their own MyFunkyStringClass, and it's use is all wrapped up in how they decided to do memory. Trying to hook that stuff up to D is such a mess it would be easier to reimplement it in D entirely.

> If I were W, I would set a 1.0 date for D and release it with the
book
> so that you will have the time to critically analize D and iron it
out

<alert comment="ianawndipootv ... i am not a writer ...">

Some years back, Bruce Eckel released one or more of his books electronically. (C/C++/Java?) Seemed like an interesting concept, but I don't have the impression that approach caught on ...

Seems to have enormous potential to "speed a 'book' to market", however. I don't think writers over the age of 22 expect to actually make any money at their endeavors. The overhead of getting a hardback / paperback to a shelf in a bookstore has top be enormous.

Seems like an electronic book could resemble a "wiki" that was more or less moderated.

</alert>

Walter wrote:
> "Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message
> news:d05a7k$pl7$2@digitaldaemon.com...
> 
>>Walter, you read those chapters - at least I hope you did - while
>>reviewing the book. Do you think it'd be easy to adapt D, e.g. via a
>>'pinterface' keyword?
> 
> 
> D can hook directly to C++ vtables, as long as the C++ class uses single
> inheritance. It becomes a COM interface. Don't actually need to worry about
> AddRef() and Release().
> 
> That said, I think the yoogest (too borrow from Trump) problem in
> interfacing with C++ is C++'s memory allocation strategies. A lot of those
> C++ libraries have their own MyFunkyStringClass, and it's use is all wrapped
> up in how they decided to do memory. Trying to hook that stuff up to D is
> such a mess it would be easier to reimplement it in D entirely.

Could this be (at least partially) alleviated with a Copy On Read strategy?

sai wrote:
> Anyway, I am not very good at using debuggers or even understand the source
> of D front end etc. My programs in D crashed too often due to bugs in my code.
> I wish, I could get a 'D' IDE with built in debugger, that works on windows.
> I wish, phobos be as extensive as java api, with at least one standard GUI api.

Yes. For D to be accepted at my work place, a D IDE, Phobos ~ Java API, a "standard" GUI library are a must. I can make do without some of these tools, but other "part-time" programmers I work with will not. Hence, we use Java or C++ .NET (C++ MFC before that).

Jason