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