• Dawid =?UTF-8?B?Q2nEmcW8YXJraWV3aWN6?= (39/39) Dec 20 2006 I'm linux user. I wish to ask you how do you work with D conviniently. ...
• Gregor Richards (17/48) Dec 20 2006 Ouch! :)
• Lutger (13/19) Dec 20 2006 v1.0 is more than name + point and time I would hope. What I think will
• Peter C. Chapin (8/14) Dec 23 2006 I know v1.0 will make a difference to me. I've been watching D, but have...
• Lutger (17/34) Dec 23 2006 I recall at least two libraries, wxD and Arc, for which their authors
• Brad Roberts (25/31) Dec 20 2006 I think you left out the most important aspect of the summary. Every on...
• Dawid =?UTF-8?B?Q2nEmcW8YXJraWV3aWN6?= (4/17) Dec 21 2006 I think you're right that D is in it's early stages and one day it will ...
• Hasan Aljudy (16/34) Dec 20 2006 I'm a windows user, and I find it quite the opposite.

Dawid =?UTF-8?B?Q2nEmcW8YXJraWV3aWN6?= <dawid.ciezarkiewicz asn.pl> writes:

I'm linux user.  I wish to ask you how do you work with D conviniently. I
mean:

When working with C, C++ or Python, PHP everything is quite simple.
Installing libraries is simple - they are old and stable. My package
manager (ArchLinux) has almost everything for those
long-time-ago-estabilished languages. And for real custom third parties
there are always things like PHP's PEAR.

But working with D is much different. Even if I set up manually everything
and get my project compiled and working - if I'd like to give my work to
somebody he will lost much of his time to setup neccesary libraries again.
Changes in the language makes last stable release of XYZ library
uncompilable, while svn version of XYZ is not working because it's
temporary broken. And that person have to be quite skilled to do everything
that I've mentioned.

That is why I was looking forward for project like DSSS, but despite the
fact it's quite unusable/broken right now I don't think that such a single
project will make everything OK if not considered as a part of
language-pack.

Upcoming D 1.0 should stabilize language for a moment, but I think nothing
will realy change because of that. v1.0 is only name + point in time -
everything will stay the same as it is. Walter will be keeping improving
core language and we will be developing our little D projects . Little and
personal because wider audience will never use them - it still will be too
hard to get them compiled and working together.

For example: mango is a great thing. I wish to have logging support in
almost every project and mango.log is what I like. But adding such
dependency will mean that potential user will have +1 potential problem.
Adding any of existing GUI libraries means one more potential problem.
Adding database support - yet another potential problem. Of course I can
make a fork of them and include them in my project - but that means tons of
additional work with patching and staying up to date. And Phobos is sooo
tiny and messy that virtualy there is nothing inside it. No real big-blocks
that you just take and glue together to get working powerfull app. So you
need libraries for almost anything.

Summaring: D may be best language, but will it ever be best development
envivorment?

What are your thoughts about it? How do you work despite these problems?

P.S. Little late here, sorry if I've written something unreadable. Goodnight
everyone. :)

Gregor Richards <Richards codu.org> writes:

Dawid Ciężarkiewicz wrote:
 <SNIP>
 That is why I was looking forward for project like DSSS, but despite the
 fact it's quite unusable/broken right now I don't think that such a single
 project will make everything OK if not considered as a part of
 language-pack.

Ouch! :)

I've tried to get DSSS working everywhere, and I wrote it because I saw 
this very hole. It needs a bit of smoothing, but if it's that 
unusable/broken for you then I think there's either something wrong with 
your environment or with how DSSS interacts with it. I haven't 
extensively tested on DMD on GNU/Linux, so if that's your environment 
that could be a problem too. I have some time and am going to do some 
hacking at it today.

 
 Upcoming D 1.0 should stabilize language for a moment, but I think nothing
 will realy change because of that. v1.0 is only name + point in time -
 everything will stay the same as it is. Walter will be keeping improving
 core language and we will be developing our little D projects . Little and
 personal because wider audience will never use them - it still will be too
 hard to get them compiled and working together.

Hear-hear.

 
 For example: mango is a great thing. I wish to have logging support in
 almost every project and mango.log is what I like. But adding such
 dependency will mean that potential user will have +1 potential problem.

This is why I made `dsss net deps` ... which is supposed to work :)

 Adding any of existing GUI libraries means one more potential problem.

Also a good point.

 Adding database support - yet another potential problem. Of course I can
 make a fork of them and include them in my project - but that means tons of
 additional work with patching and staying up to date. And Phobos is sooo
 tiny and messy that virtualy there is nothing inside it. No real big-blocks
 that you just take and glue together to get working powerfull app. So you
 need libraries for almost anything.
 
 Summaring: D may be best language, but will it ever be best development
 envivorment?

Hear-hear.

 
 What are your thoughts about it? How do you work despite these problems?

I find myself fighting Phobos a lot. I think that a bit of smoothing of 
DSSS and a bit more pimping of DSSS could solve some issues, but that 
may be in part a pipe-dream.

 
 P.S. Little late here, sorry if I've written something unreadable. Goodnight
 everyone. :)

  - Gregor Richards

Lutger <lutger.blijdestijn gmail.com> writes:

Dawid Ciężarkiewicz wrote:
 Upcoming D 1.0 should stabilize language for a moment, but I think nothing
 will realy change because of that. v1.0 is only name + point in time -
 everything will stay the same as it is. Walter will be keeping improving
 core language and we will be developing our little D projects . Little and
 personal because wider audience will never use them - it still will be too
 hard to get them compiled and working together.

v1.0 is more than name + point and time I would hope. What I think will 
happen is that at least some, if not most or even all libraries will 
stay compatible with the v1 switch and bugfixes will find their way in 
v1 too, but not changes. Now that should stabilize the D 'platform' and 
allow for less of these problems, isn't this exactly the reason for a 
1.0 version?  (Besides marketing purposes)

I think that between bud/dsss and v1.0, D will be a very easy platform 
to build for. I admit not doing any big stuff, but still I find building 
and using libraries for D is *much* easier than what I was used to with 
C++, especially if you use libraries made for different compilers (or 
even versions of same compilers). Simply put, bud beats the crap out of 
makefiles&co! Very lucky we have this tool.

"Peter C. Chapin" <pchapin sover.net> writes:

Lutger <lutger.blijdestijn gmail.com> wrote in
news:emcoci$3ep$1 digitaldaemon.com: 

 v1.0 is more than name + point and time I would hope. What I think
 will happen is that at least some, if not most or even all libraries
 will stay compatible with the v1 switch and bugfixes will find their
 way in v1 too, but not changes. Now that should stabilize the D
 'platform' and allow for less of these problems, isn't this exactly
 the reason for a 1.0 version?

I know v1.0 will make a difference to me. I've been watching D, but have  
been reluctant to spend much time working with it. I realize that a 1.0 
release is somewhat arbitrary but it does represent a fixed point in the 
language's development. Once 1.0 is ready I hope to start working with D 
"for real." I'm sure there are others in the same position.

Peter

Lutger <lutger.blijdestijn gmail.com> writes:

Peter C. Chapin wrote:
 Lutger <lutger.blijdestijn gmail.com> wrote in
 news:emcoci$3ep$1 digitaldaemon.com: 
 
 v1.0 is more than name + point and time I would hope. What I think
 will happen is that at least some, if not most or even all libraries
 will stay compatible with the v1 switch and bugfixes will find their
 way in v1 too, but not changes. Now that should stabilize the D
 'platform' and allow for less of these problems, isn't this exactly
 the reason for a 1.0 version?

 
 I know v1.0 will make a difference to me. I've been watching D, but have  
 been reluctant to spend much time working with it. I realize that a 1.0 
 release is somewhat arbitrary but it does represent a fixed point in the 
 language's development. Once 1.0 is ready I hope to start working with D 
 "for real." I'm sure there are others in the same position.
 
 Peter

I recall at least two libraries, wxD and Arc, for which their authors 
plan on making a corresponding release with D 1.0.

I think the idea that 1.0 is an arbitrary point is time is becoming 
obsolete. That was perhaps the case when Walter posed the question: 'is 
0.163 1.0?' or something like that a while back, but this time the 
version number is a more rational mark:
- numerous important and code breaking features have been added with the 
explicit intention that it would be good to have them before 1.0
- name mangling, abi changes, spec cleanup.
- a switch to compile for 1.0
There is nothing arbritray about these changes since they are at least 
partly motivated by the coming 1.0 release. If the release gets delayed 
a little (I expect so) that is another indicator that 1.0 is not arbitrary.

This means that 1.0 is more than just a snapshot in time, as it comes at 
a time where D is quite comprehensive and it is reasonable to develop 
with this fixed set of features. Soon D will not be a moving target anymore.

Brad Roberts <braddr puremagic.com> writes:

On Thu, 21 Dec 2006, Dawid Ciarkiewicz wrote:

 Summarizing: D may be best language, but will it ever be best
 development environment?

I think you left out the most important aspect of the summary.  Every one 
of the languages you mentioned also went through a phase of it's life 
where it was just as immature as the current state of D.  Over them, all 
of them grew into what they are today through the hard work of a many many 
people (and often many companies).  None of them sprung out of nowhere 
fully matured.

 What are your thoughts about it? How do you work despite these problems?
 
 P.S. Little late here, sorry if I've written something unreadable. Goodnight
 everyone. :)

My thoughts are simple:  D is still in an early phase of life where it's 
not reached the level of maturity that a lot of people expect looking at 
it for the first time.  Expectations a major guide to how anything is 
perceived and that ends to make D look bad.  It's unfortunate but true.  
Over the time I've been involved with D (admittedly not terribly long, a 
little over a year), I've seen it grow in some and I expect that growth to 
accelerate over the next few years.  It takes the time and energy of many 
people to achieve the sort level of maturity that D needs to have to be 

little doubt that the community _will_ get there.

In many ways it's a catch-22 situation that takes brave individuals to 
overcome.  Without the maturity people won't use it.  Without people using 
it, it can't reach maturity.

So.. my parting thought.  Be brave!  Help the rest of us raise D up to the 
level that it can exceed expectations and replace some of the current 
language leaders.

Later,
Brad

Dawid =?UTF-8?B?Q2nEmcW8YXJraWV3aWN6?= <dawid.ciezarkiewicz asn.pl> writes:

Brad Roberts wrote:

 My thoughts are simple:  D is still in an early phase of life where it's
 not reached the level of maturity that a lot of people expect looking at
 it for the first time.  Expectations a major guide to how anything is
 perceived and that ends to make D look bad.  It's unfortunate but true.
 Over the time I've been involved with D (admittedly not terribly long, a
 little over a year), I've seen it grow in some and I expect that growth to
 accelerate over the next few years.  It takes the time and energy of many
 people to achieve the sort level of maturity that D needs to have to be

 little doubt that the community _will_ get there.

I think you're right that D is in it's early stages and one day it will get
there - along with other the long-time-ago-estabilished.

 So.. my parting thought.  Be brave!  Help the rest of us raise D up to the
 level that it can exceed expectations and replace some of the current
 language leaders.

I'll keep trying. :)

Hasan Aljudy <hasan.aljudy gmail.com> writes:

Dawid Ciężarkiewicz wrote:
 I'm linux user.  I wish to ask you how do you work with D conviniently. I
 mean:
 
 When working with C, C++ or Python, PHP everything is quite simple.
 Installing libraries is simple - they are old and stable. My package
 manager (ArchLinux) has almost everything for those
 long-time-ago-estabilished languages. And for real custom third parties
 there are always things like PHP's PEAR.

I'm a windows user, and I find it quite the opposite.
Working with C/C++/PHP never made sense to me. I always have to use some 
IDE of some sort, along with automatic installers that put everything in 
its _magical_ place to make everything work together _magically_. all 
the libraries and the thousands of header files .. all the dependencies 
.. oh my God!!

With D, there's no such thing. dmd is a command line tool. build (now 
known as bud) takes care of compiling a project. No registery files. No 
magic, things are simple and they just work. No library files needed, 
because dmd is so fast that I'd rather use the library source directly.

 
 But working with D is much different. Even if I set up manually everything
 and get my project compiled and working - if I'd like to give my work to
 somebody he will lost much of his time to setup neccesary libraries again.
 Changes in the language makes last stable release of XYZ library
 uncompilable, while svn version of XYZ is not working because it's
 temporary broken. And that person have to be quite skilled to do everything
 that I've mentioned.

Being on windows, I just compile an .exe that can go to any other 
windows machine.
However, working with linux .. I see what you mean.
But still though, you say:

 that person have to be quite skilled to do everything
 that I've mentioned.

Isn't that true of everything in linux?