www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Key issue for PhanTango?

reply "Kris" <foo bar.com> writes:
I'm going to push this up for comment since I suspect it is a key factor:

http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=60063

Opinions?  Is this what matters to people? 
Oct 11 2007
next sibling parent David Brown <dlang davidb.org> writes:
On Thu, Oct 11, 2007 at 10:12:39PM -0700, Kris wrote:
I'm going to push this up for comment since I suspect it is a key factor:

http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=60063

Opinions?  Is this what matters to people? 
In the ideal world, I think it should be possible to link together pieces of code that were writting for both Phobos and Tango. I don't know how realistic this is with all of the differences in I/O. I wonder how much work it would be to have a more complete Phobos compability tree as part of Tango. David
Oct 11 2007
prev sibling next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Kris wrote:
 I'm going to push this up for comment since I suspect it is a key factor:
 
 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=60063
 
 Opinions?  Is this what matters to people? 
Is what what matters? The link is to your response to someone. Did you mean to link to his post? Is what he said what you're referring to ("The main issue from my point of view is compatibility...")? If so isn't that what everyone's been saying all along from the first day it was announced Tango would be incompatible? --bb
Oct 11 2007
parent "Kris" <foo bar.com> writes:
"Bill Baxter" <dnewsgroup billbaxter.com> wrote in message 
news:fen2p0$2ham$1 digitalmars.com...
 Kris wrote:
 I'm going to push this up for comment since I suspect it is a key factor:

 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=60063

 Opinions?  Is this what matters to people?
Is what what matters? The link is to your response to someone. Did you mean to link to his post? Is what he said what you're referring to ("The main issue from my point of view is compatibility...")? If so isn't that what everyone's been saying all along from the first day it was announced Tango would be incompatible?
It's the /extent/ or /depth/ of that needed compatability that I wish to clarify ... Peter is basically saying the whole thing would need to be compatible, while some other folk have indicated just toString() et. al. would do the job ...
Oct 12 2007
prev sibling next sibling parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Kris wrote:
 I'm going to push this up for comment since I suspect it is a key factor:
 
 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=60063
 
 Opinions?  Is this what matters to people? 
 
 
Yes it matters, for this is one key benefit of a *standard* library. However for me, it is not the main problem. Worse is that, for example, one cannot compile Tango programs with phobos libraries. Rather than an all or nothing approach, I would prefer this to change, which is much less problematic to solve too. In C++ there are far worse situations, like not being able to use STL containers with wxWidgets. I dont't think it'll be so bad here, and Tango is a reasonable dependency to have if it were compatible with the phobos runtime.
Oct 12 2007
parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Lutger wrote:

 Kris wrote:
 I'm going to push this up for comment since I suspect it is a key factor:
 
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=60063
 
 Opinions?  Is this what matters to people?
 
 
Yes it matters, for this is one key benefit of a *standard* library. However for me, it is not the main problem. Worse is that, for example, one cannot compile Tango programs with phobos libraries. Rather than an all or nothing approach, I would prefer this to change, which is much less problematic to solve too.
Do mean like Tangobos? Or that Tango runs on Phobos' runtime? -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Oct 12 2007
parent Lutger <lutger.blijdestijn gmail.com> writes:
Lars Ivar Igesund wrote:
 Lutger wrote:
 
 Kris wrote:
 I'm going to push this up for comment since I suspect it is a key factor:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=60063
 Opinions?  Is this what matters to people?
Yes it matters, for this is one key benefit of a *standard* library. However for me, it is not the main problem. Worse is that, for example, one cannot compile Tango programs with phobos libraries. Rather than an all or nothing approach, I would prefer this to change, which is much less problematic to solve too.
Do mean like Tangobos? Or that Tango runs on Phobos' runtime?
Both achieve the same purpose, which is most important. However I get the impression that the Tango runtime is better designed and arguments have been made this is an integral part of Tango. Actually I don't think I'm knowledgeable enough about the runtime and rather trust your (the Tango team, and also Walter Bright) judgement on this, so I don't have much to say here.
Oct 12 2007
prev sibling next sibling parent Simas <simas gmx.net> writes:
Kris Wrote:

 
 "Bill Baxter" <dnewsgroup billbaxter.com> wrote in message 
 news:fen2p0$2ham$1 digitalmars.com...
 Kris wrote:
 I'm going to push this up for comment since I suspect it is a key factor:

 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=60063

 Opinions?  Is this what matters to people?
Is what what matters? The link is to your response to someone. Did you mean to link to his post? Is what he said what you're referring to ("The main issue from my point of view is compatibility...")? If so isn't that what everyone's been saying all along from the first day it was announced Tango would be incompatible?
... Peter is basically saying the whole thing would need to be compatible, ...
This is what i said in http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=58448 The main problem is how to bring phobos and tango user together? Maybe tangobos helps, because phobos people want free function style instead member functions. (IMHO the free function style and the API is simpler to learn.) Maybe there are more things which phobos user want, but until Walter say "let us merge the libraries", this problem can't be solved. The question is: What will Walter?
Oct 12 2007
prev sibling next sibling parent Regan Heath <regan netmail.co.nz> writes:
Kris wrote:
 I'm going to push this up for comment since I suspect it is a key factor:
 
 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=60063
 
 Opinions?  Is this what matters to people? 
I think Michael hit the nail on the head: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=60065 I don't use Tango at the moment because it's incompatible with Phobos. That said I have only worked on what I would call "toy" projects in D so far, so it may be that if I had a pressing need I would go to the trouble of figuring out how to install and use Tango. In my ideal world I would be able to write code using modules from both Phobos and Tango at the same time and with no more hassle than "download and provide the paths to the compiler". I want to be able to cherry pick the functionality I need without restriction. That said, I would accept restrictions to how they can be used together, say for example that I could not mix calls to phobos IO and tango IO and expect them to buffer/interleave correctly in the output. (This may even be solvable with some optional common buffering of some sort, who knows) So I guess my basic position is that the core runtime stuff i.e. object, exception, the GC, etc needs to merge (and may the best one win) and the rest (both phobos and tango) should be layered on the top in some coherent fashion either as 1 library or several. Regan
Oct 12 2007
prev sibling next sibling parent Daniel Keep <daniel.keep.lists gmail.com> writes:
Kris wrote:
 I'm going to push this up for comment since I suspect it is a key factor:
 
 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=60063
 
 Opinions?  Is this what matters to people? 
I've worked hard on a lot of the libraries I've written so that they work in both Phobos and Tango out of the box. One that I'm working on currently is my XML library. Usually, the differences between Tango and Phobos aren't that big. For instance, my Variant type had a small set of functions at the top that abstracted the differences between Phobos and Tango without too much trouble. Even the toString/toUtf8 thing can be worked around by having a free templated function that switches for you. The big one I'm running into at the moment is IO, basically due to the large differences between the two. I'm considering writing a very simply util.io library that allows for basic reading/writing on either Tango or Phobos streams, depending on which is being compiled. But really, the only thing that I can't work around easily is the fact that the runtimes are incompatible. Pretty much everything else can be dealt with. I think that we should just concentrate on getting both running on the same runtime (which, let's face it, is probably going to end up as Tango's runtime). Higher-level compatibility can be taken care of as needed. Just my AU$0.02. -- Daniel
Oct 12 2007
prev sibling next sibling parent reply Aarti_pl <aarti interia.pl> writes:
Kris pisze:
 I'm going to push this up for comment since I suspect it is a key factor:
 
 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=60063
 
 Opinions?  Is this what matters to people? 
 
 
I was sure that compatibility with Phobos is already decided by Tango team (as a goal). That's why I posted: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=59960 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=59989 which is my vision of coexistence of both libraries peacefully together. :-) But from different posts I can see that compatibility (in meaning that both api's will be allowed) is not decided yet. It will be really loose-loose situation when D user will have to decide which library is she using, and then will not be able to use other libraries from "opposite camp". BR Marcin Kuszczak (aarti_pl - www.zapytajmnie.com)
Oct 12 2007
parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Aarti_pl wrote:

 Kris pisze:
 I'm going to push this up for comment since I suspect it is a key factor:
 
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=60063
 
 Opinions?  Is this what matters to people?
 
 
I was sure that compatibility with Phobos is already decided by Tango team (as a goal). That's why I posted:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=59960

http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=59989
 
 which is my vision of coexistence of both libraries peacefully together.
 :-)
 
 But from different posts I can see that compatibility (in meaning that
 both api's will be allowed) is not decided yet.
Compatibility with Phobos as far as the Tango team is concerned, has always been about the runtime, meaning that both libraries should run completely and correctly on top of the same runtime. Now, not even this is easy. For all practical purposes, Phobos will have to almost literally import all of Tango's runtime for Tango to work on top of Phobos'. The other way round is probably much easier as shown with Tangobos.
 It will be really loose-loose situation when D user will have to decide
 which library is she using, and then will not be able to use other
 libraries from "opposite camp".
In general you can as long as the runtimes are compatible. Overlapping functionality may become a problem in terms of compatibility if one library uses Tango and the other Phobos for say IO streams, but as said earlier. Making Tango (any part related to IO especially) a wrapper around Phobos don't at all make sense in that respect, and will not happen. If someone wants to do the opposite, or create a wrapper around both, sure. You seem to think that the Tango team should be ahead of such a process, but considering that we already solved our problems by not using Phobos, that would be a turn in the wrong direction for us? Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Oct 12 2007
parent reply Aarti_pl <aarti interia.pl> writes:
Lars Ivar Igesund pisze:
 In general you can as long as the runtimes are compatible. Overlapping
 functionality may become a problem in terms of compatibility if one library
 uses Tango and the other Phobos for say IO streams, but as said earlier.
 Making Tango (any part related to IO especially) a wrapper around Phobos
 don't at all make sense in that respect, and will not happen. If someone
 wants to do the opposite, or create a wrapper around both, sure. You seem
 to think that the Tango team should be ahead of such a process, but
 considering that we already solved our problems by not using Phobos, that
 would be a turn in the wrong direction for us?
 
In fact I think there is necessary dialog between Tango team AND Walter to solve problem. I was not suggesting that Tango should work on top of Phobos. I was rather suggesting that profiling libraries (Phobos - low level; Tango - higher level) will cause to be *much less* conflicting points between libraries and better synergy while keeping relative high independence between authors of libraries. In such a case BOTH libraries could be threated as standard. And once again: I don't think that if there will be Phobos's writefln(), there can not be Cout() from Tango. IMHO there is no problem that there would be both, having completely different implementation. (Probably there will be need for some synchronization, between them, to allow interchangeable usage, but i am not sure.) My proposal is rather to keep most used Phobos'es methods/classes in Phobos, remove from Phobos high level function/classes (eg. net?). From Tango should migrate to Phobos free functions (Math?, Variant?, core/ directory?). I don't want to go much into details because it needs much better analysis than I can give. My post is more about choosing good strategy to merge libraries... But maybe I just don't see, why it is not possible to choose such a strategy... Then please let me/us know why it won't work, if I can ask... Also nobody from community has commented about such idea, so maybe it's just wrong way... Would be great to get some more opinions... BR Marcin Kuszczak (aarti_pl - www.zapytajmnie.com)
Oct 12 2007
next sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Aarti_pl wrote:

 Lars Ivar Igesund pisze:
 In general you can as long as the runtimes are compatible. Overlapping
 functionality may become a problem in terms of compatibility if one
 library uses Tango and the other Phobos for say IO streams, but as said
 earlier. Making Tango (any part related to IO especially) a wrapper
 around Phobos don't at all make sense in that respect, and will not
 happen. If someone wants to do the opposite, or create a wrapper around
 both, sure. You seem to think that the Tango team should be ahead of such
 a process, but considering that we already solved our problems by not
 using Phobos, that would be a turn in the wrong direction for us?
 
In fact I think there is necessary dialog between Tango team AND Walter to solve problem.
Yes, there is a dialog between us and Walter, but I suppose I don't understand what is the problem you want us to solve.
 My proposal is rather to keep most used Phobos'es methods/classes in
 Phobos, remove from Phobos high level function/classes (eg. net?). From
 Tango should migrate to Phobos free functions (Math?, Variant?, core/
 directory?).
But we are developing this stuff in Tango, not Phobos. In essence you are suggesting one repository containing both Tango and Phobos, resulting in one download. Merging code is only one problem, the practical problems to merge the _projects_ would be quite different and would in practice Phobos and Tango independence. Any other solution to this would lead to code being duplicated, and needed to be mantained in several places.
 But maybe I just don't see, why it is not possible to choose such a
 strategy... Then please let me/us know why it won't work, if I can ask...
It is possible, I just don't think there currently is a good and compelling reason for doing it? -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Oct 12 2007
parent Aarti_pl <aarti interia.pl> writes:
Lars Ivar Igesund pisze:
 Aarti_pl wrote:
> Yes, there is a dialog between us and Walter, but I suppose I don't
 understand what is the problem you want us to solve. 
 
Compatibility. I just don't want to choose one library and loose functionality in other. And then if it will happen, I want that there will be not much duplicated functionality. BR Marcin Kuszczak (aarti_pl www.zapytajmnie.com)
Oct 12 2007
prev sibling parent "Kris" <foo bar.com> writes:
"Aarti_pl" <aarti interia.pl> wrote in message 
news:fenpj3$2c84$1 digitalmars.com...
 Also nobody from community has commented about such idea, so maybe it's 
 just wrong way... Would be great to get some more opinions...
Marcin, I did reply to your idea in an earlier post
Oct 12 2007
prev sibling parent reply Charles D Hixson <charleshixsn earthlink.net> writes:
Kris wrote:
 I'm going to push this up for comment since I suspect it is a key factor:
 
 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=60063
 
 Opinions?  Is this what matters to people? 
 
 
I don't feel that one needs to be able to use both libraries in the same module, but when linking modules together it is important that it not matter that they have been compiled with the same library. I.e., if I get library A from one source and library B from another source, I should expect to be able to link both into my program...and it shouldn't matter whether I'm using Phobos or Tango, or which the libraries used, except insofar as dependencies that need to be satisfied. For that matter, if one file is opened with one library, I don't insist that the other library be able to operate on it without closing and reopening it. (EXCEPTION: stdin, stdout, and stderr should be dealt with using methods that are compatible and allow interleaving...though this might be allowed to affect the order of line transmission on a line-by-line basis.)
Oct 13 2007
next sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On 10/14/07, Charles D Hixson <charleshixsn earthlink.net> wrote:
 I don't feel that one needs to be able to use both libraries
 in the same module,
Not sure exactly what you mean by that, but unless I can do import std.whatever; import tango.whatever; both in the same source file, then I'm unlikely to use Tango. If I /can/ do that, then I'd start to explore it.
Oct 13 2007
prev sibling parent reply "Kris" <foo bar.com> writes:
From all the threads so far, this is what I've surmised:

For those people who need to run Tango-based and phobos-based code 
side-by-side, it appears to be fine that the higher-level elements are 
different. As long as the principal modules of both operate happily on some 
common runtime package, then it's cool.

Based on that assertion, we'll make some changes and get it working. If the 
assertion is not correct, then please say so ...

- Kris



"Charles D Hixson" <charleshixsn earthlink.net> wrote in message
 I don't feel that one needs to be able to use both libraries in the same 
 module, but when linking modules together it is important that it not 
 matter that they have been compiled with the same library.

 I.e., if I get library A from one source and library B from another 
 source, I should expect to be able to link both into my program...and it 
 shouldn't matter whether I'm using Phobos or Tango, or which the libraries 
 used, except insofar as dependencies that need to be satisfied.

 For that matter, if one file is opened with one library, I don't insist 
 that the other library be able to operate on it without closing and 
 reopening it.  (EXCEPTION:  stdin, stdout, and stderr should be dealt with 
 using methods that are compatible and allow interleaving...though this 
 might be allowed to affect the order of line transmission on a 
 line-by-line basis.) 
Oct 14 2007
next sibling parent reply Yigal Chripun <yigal100 gmail.com> writes:
Kris wrote:
 From all the threads so far, this is what I've surmised:
 
 For those people who need to run Tango-based and phobos-based code 
 side-by-side, it appears to be fine that the higher-level elements are 
 different. As long as the principal modules of both operate happily on some 
 common runtime package, then it's cool.
 
 Based on that assertion, we'll make some changes and get it working. If the 
 assertion is not correct, then please say so ...
 
 - Kris
 
 
 
 "Charles D Hixson" <charleshixsn earthlink.net> wrote in message
 I don't feel that one needs to be able to use both libraries in the same 
 module, but when linking modules together it is important that it not 
 matter that they have been compiled with the same library.

 I.e., if I get library A from one source and library B from another 
 source, I should expect to be able to link both into my program...and it 
 shouldn't matter whether I'm using Phobos or Tango, or which the libraries 
 used, except insofar as dependencies that need to be satisfied.

 For that matter, if one file is opened with one library, I don't insist 
 that the other library be able to operate on it without closing and 
 reopening it.  (EXCEPTION:  stdin, stdout, and stderr should be dealt with 
 using methods that are compatible and allow interleaving...though this 
 might be allowed to affect the order of line transmission on a 
 line-by-line basis.) 
i'm just one person, but IMHO isn't that just a patch of sorts for the near future? I do realize that's merging both phobos and tango is a lot of work. With your suggestion all we get is a standardized runtime, Which is by itself a very important thing, but for the long run, D needs a standard library too, which is to say a standard API. Until we reach a merged, agreed by all one API, there is no standard library for D in my mind. my personal preference would be to discard phoboes (i don't want the C runtime unless i asked for it explicitly...) and use the tango code base, of course after fixing the problems In the API people mentioned in the NG and adding missing features from phoboes to tango. for example the console interface should be simplified as others suggested. i think Tango is better designed and it would be easier to add to tango rather than than redesigning phoboes. besides those rough edges tango is great so keep up the good work :) thanks for working on this great project! please comment if you agree/disagree with me. P.S i'd prefer either be able to import Cout and just have two functions like print/println with formatting, or changing Cout to out (no upper case letters, and without C-style shortcut names) I prefer more readable java style with camel case full names rather than c/c++ 3 letter abbreviations like ptr instead of pointer, buf instead of buffer and etc.. (we all know that we read code a lot more than we write it, so it's better to write longerIdentifierNames which would be easier to read and understand later)
Oct 14 2007
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Yigal Chripun wrote:
 ...
 Until we reach a merged, agreed by all one API, there is no standard
 library for D in my mind.
"agreed by all one API" Yeah, I don't think that's gonna happen. Ever. You're asking programmers to unilaterally agree on a large, complex topic. These are the people who continually rewrite stuff because of "not invented here" or "don't like the capitalisation on the identifiers" or "because I felt like it" syndromes... :P
 ...
 
 P.S
 i'd prefer either be able to import Cout and just have two functions
 like print/println with formatting, or changing Cout to out (no upper
 case letters, and without C-style shortcut names)
 I prefer more readable java style with camel case full names rather than
 c/c++ 3 letter abbreviations like ptr instead of pointer, buf instead of
 buffer and etc.. (we all know that we read code a lot more than we write
 it, so it's better to write longerIdentifierNames which would be easier
 to read and understand later)
See, and I prefer the terseness of C. One thing that always made me want to throw the computer out the window when programming Java was the fact that every damn statement took, at minimum, three lines to do anything constructive just because all the identifiers were so bloody long. I want to write code. Not a dissertation. When you've got names that long, you just end up with this dense, unreadable mess. Besides, if the names are a little bit cryptic, people will actually take the time to carefully read the code to make sure they understand it instead of assuming they know what it means, which is *clearly* better. Give me function names I can type in under three seconds and some decent comments any day. And that's the problem. I think that for some people Phobos is better because it's a lot like the standard C library. They like it like that. That's why I think all the calls for a complete merge are a bit silly; D's unique AFAIK in that it's got a very lean, simple API and a much more powerful, more complete API. Make them compatible, sure, but keep them separate. Don't take away our toys just because *you* don't play with them. :) -- Daniel
Oct 14 2007
next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Daniel Keep wrote:
 Yigal Chripun wrote:
 ...
 Until we reach a merged, agreed by all one API, there is no standard
 library for D in my mind.
"agreed by all one API" Yeah, I don't think that's gonna happen. Ever. You're asking programmers to unilaterally agree on a large, complex topic. These are the people who continually rewrite stuff because of "not invented here" or "don't like the capitalisation on the identifiers" or "because I felt like it" syndromes... :P
Agreed. "One standard library" is no more likely to occur than "one standard gui". Or "one standard programming language". Or "one standard operating system", etc. --bb
Oct 14 2007
prev sibling next sibling parent Don Clugston <dac nospam.com.au> writes:
Daniel Keep wrote:
 Yigal Chripun wrote:
 ...
 Until we reach a merged, agreed by all one API, there is no standard
 library for D in my mind.
"agreed by all one API" Yeah, I don't think that's gonna happen. Ever. You're asking programmers to unilaterally agree on a large, complex topic. These are the people who continually rewrite stuff because of "not invented here" or "don't like the capitalisation on the identifiers" or "because I felt like it" syndromes... :P
 ...

 P.S
 i'd prefer either be able to import Cout and just have two functions
 like print/println with formatting, or changing Cout to out (no upper
 case letters, and without C-style shortcut names)
 I prefer more readable java style with camel case full names rather than
 c/c++ 3 letter abbreviations like ptr instead of pointer, buf instead of
 buffer and etc.. (we all know that we read code a lot more than we write
 it, so it's better to write longerIdentifierNames which would be easier
 to read and understand later)
See, and I prefer the terseness of C. One thing that always made me want to throw the computer out the window when programming Java was the fact that every damn statement took, at minimum, three lines to do anything constructive just because all the identifiers were so bloody long. I want to write code. Not a dissertation. When you've got names that long, you just end up with this dense, unreadable mess. Besides, if the names are a little bit cryptic, people will actually take the time to carefully read the code to make sure they understand it instead of assuming they know what it means, which is *clearly* better. Give me function names I can type in under three seconds and some decent comments any day. And that's the problem. I think that for some people Phobos is better because it's a lot like the standard C library. They like it like that. That's why I think all the calls for a complete merge are a bit silly; D's unique AFAIK in that it's got a very lean, simple API and a much more powerful, more complete API. Make them compatible, sure, but keep them separate. Don't take away our toys just because *you* don't play with them. :)
We can probably do a bit better than that. I think that if we get the runtime sorted out, so that both Phobos and Tango can both be used together, then it ought to be possible to merge a lot of the implementation code. But as long as they can't be used together, the situation is hopeless.
Oct 14 2007
prev sibling next sibling parent Yigal Chripun <yigal100 gmail.com> writes:
Daniel Keep wrote:
 Yigal Chripun wrote:
 ...
 Until we reach a merged, agreed by all one API, there is no standard
 library for D in my mind.
"agreed by all one API" Yeah, I don't think that's gonna happen. Ever. You're asking programmers to unilaterally agree on a large, complex topic. These are the people who continually rewrite stuff because of "not invented here" or "don't like the capitalisation on the identifiers" or "because I felt like it" syndromes... :P
 ...

 P.S
 i'd prefer either be able to import Cout and just have two functions
 like print/println with formatting, or changing Cout to out (no upper
 case letters, and without C-style shortcut names)
 I prefer more readable java style with camel case full names rather than
 c/c++ 3 letter abbreviations like ptr instead of pointer, buf instead of
 buffer and etc.. (we all know that we read code a lot more than we write
 it, so it's better to write longerIdentifierNames which would be easier
 to read and understand later)
See, and I prefer the terseness of C. One thing that always made me want to throw the computer out the window when programming Java was the fact that every damn statement took, at minimum, three lines to do anything constructive just because all the identifiers were so bloody long. I want to write code. Not a dissertation. When you've got names that long, you just end up with this dense, unreadable mess. Besides, if the names are a little bit cryptic, people will actually take the time to carefully read the code to make sure they understand it instead of assuming they know what it means, which is *clearly* better. Give me function names I can type in under three seconds and some decent comments any day. And that's the problem. I think that for some people Phobos is better because it's a lot like the standard C library. They like it like that. That's why I think all the calls for a complete merge are a bit silly; D's unique AFAIK in that it's got a very lean, simple API and a much more powerful, more complete API. Make them compatible, sure, but keep them separate. Don't take away our toys just because *you* don't play with them. :) -- Daniel
well, maybe "agreed by all one API" was to strong a statement, but what i really meant was something like the STL for C++. you do have alternative libraries you could use but STL comes with all modern C++ compilers and is considered by the community as the standard library. i do agree that java is too verbose a language, but that's because of its structure and design (lack of operator overloading, protection attributes on each function without being able to group them, etc... ) if you take a richer language like D with the Java _style_ you could get relatively short code which is more readable, IMO. you don't really have to have two distinct APIs with different code bases in order to have two different styles of coding. i think creating a merged super-set of both APIs on top of tango would in fact create one more complete API which you could use a subset of, which gives you that C feel you seek. the benefits to that approach is having different complimentary "views" of the same codebase thus having one IO subsystem for example.
Oct 15 2007
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Daniel Keep wrote:
 Yigal Chripun wrote:
 ...
 Until we reach a merged, agreed by all one API, there is no standard
 library for D in my mind.
"agreed by all one API" Yeah, I don't think that's gonna happen. Ever. You're asking programmers to unilaterally agree on a large, complex topic. These are the people who continually rewrite stuff because of "not invented here" or "don't like the capitalisation on the identifiers" or "because I felt like it" syndromes... :P
 ...

 P.S
 i'd prefer either be able to import Cout and just have two functions
 like print/println with formatting, or changing Cout to out (no upper
 case letters, and without C-style shortcut names)
 I prefer more readable java style with camel case full names rather than
 c/c++ 3 letter abbreviations like ptr instead of pointer, buf instead of
 buffer and etc.. (we all know that we read code a lot more than we write
 it, so it's better to write longerIdentifierNames which would be easier
 to read and understand later)
See, and I prefer the terseness of C. One thing that always made me want to throw the computer out the window when programming Java was the fact that every damn statement took, at minimum, three lines to do anything constructive just because all the identifiers were so bloody long. I want to write code. Not a dissertation. When you've got names that long, you just end up with this dense, unreadable mess. Besides, if the names are a little bit cryptic, people will actually take the time to carefully read the code to make sure they understand it instead of assuming they know what it means, which is *clearly* better. Give me function names I can type in under three seconds and some decent comments any day.
Use code auto-completion. Code completion is on average even faster than typing *terse* function names, unless the vast majority of your function names has only 3-4 characters or less... If you don't like full blown IDEs, code completion should be available in traditional text editors (such as Vim or Emacs) as well (I'm talking about programming languages in general, not about D in particular). And verbose names are not "unreadable". Quite the contrary, they are more readable than terse and (quote) "cryptic" names. That's why their called cryptic... -- Bruno Medeiros - MSc in CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 15 2007
prev sibling next sibling parent Simas <simas gmx.net> writes:
Don Clugston Wrote:

 Daniel Keep wrote:
 Yigal Chripun wrote:
 ...
 Until we reach a merged, agreed by all one API, there is no standard
 library for D in my mind.
"agreed by all one API" Yeah, I don't think that's gonna happen. Ever. You're asking programmers to unilaterally agree on a large, complex topic. These are the people who continually rewrite stuff because of "not invented here" or "don't like the capitalisation on the identifiers" or "because I felt like it" syndromes... :P
 ...

 P.S
 i'd prefer either be able to import Cout and just have two functions
 like print/println with formatting, or changing Cout to out (no upper
 case letters, and without C-style shortcut names)
 I prefer more readable java style with camel case full names rather than
 c/c++ 3 letter abbreviations like ptr instead of pointer, buf instead of
 buffer and etc.. (we all know that we read code a lot more than we write
 it, so it's better to write longerIdentifierNames which would be easier
 to read and understand later)
See, and I prefer the terseness of C. One thing that always made me want to throw the computer out the window when programming Java was the fact that every damn statement took, at minimum, three lines to do anything constructive just because all the identifiers were so bloody long. I want to write code. Not a dissertation. When you've got names that long, you just end up with this dense, unreadable mess. Besides, if the names are a little bit cryptic, people will actually take the time to carefully read the code to make sure they understand it instead of assuming they know what it means, which is *clearly* better. Give me function names I can type in under three seconds and some decent comments any day. And that's the problem. I think that for some people Phobos is better because it's a lot like the standard C library. They like it like that. That's why I think all the calls for a complete merge are a bit silly; D's unique AFAIK in that it's got a very lean, simple API and a much more powerful, more complete API. Make them compatible, sure, but keep them separate. Don't take away our toys just because *you* don't play with them. :)
We can probably do a bit better than that. I think that if we get the runtime sorted out, so that both Phobos and Tango can both be used together, then it ought to be possible to merge a lot of the implementation code. But as long as they can't be used together, the situation is hopeless.
Agreed. What i miss is the statement of Walter. How do you think about the phobos future? Is phobos completed or is phobos 2.0 planned? This may help to solve the incompatibility problem.
Oct 15 2007
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Kris" wrote
 From all the threads so far, this is what I've surmised:

 For those people who need to run Tango-based and phobos-based code 
 side-by-side, it appears to be fine that the higher-level elements are 
 different. As long as the principal modules of both operate happily on 
 some common runtime package, then it's cool.

 Based on that assertion, we'll make some changes and get it working. If 
 the assertion is not correct, then please say so ...
I think this is the right move, fix the least common denominator, and get the thing working. If we can find a way to merge the higher level constructs, then it can be accomplished later. This is not a perfect example, but I look at it as a similar situation to FILE * and printf vs. std::ostream and operator<<. Both are accessible from C++, and they use different buffering techniques, which means you can't interleave them and expect any deterministic ordering. Some people prefer printf, and that is fine, others prefer the streaming method and that is also fine. But there is not a restriction of "if you use a library with printf's you can't use a library with C++ streams" like there is in D... -Steve
Oct 15 2007