www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - How to work with D?

reply 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. :)
Dec 20 2006
next sibling parent 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
Dec 20 2006
prev sibling next sibling parent reply 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.
Dec 20 2006
parent reply "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
Dec 23 2006
parent 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.
Dec 23 2006
prev sibling next sibling parent reply 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
Dec 20 2006
parent 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. :)
Dec 21 2006
prev sibling parent 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?
Dec 20 2006