www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Merging Tangobos into Tango

reply =?ISO-8859-1?Q?Julio_C=E9sar_Carrascal_Urquijo?= writes:
It seams the Phobos 1.0 vs Tango 1.0 isn't going to be fixed and we'll 
have to wait for D 2 for a solution for this problem.

Would the Tango developers consider merging Tangobos into current Tango 
in order to have a standard solution to the problem? (instead of one 
that's marked as temporary).

Thanks
Oct 09 2007
parent reply "Kris" <foo bar.com> writes:
 Would the Tango developers consider merging Tangobos into current Tango in 
 order to have a standard solution to the problem?

Merging Tangobos into Tango would appear to make only a minor difference when one can simply downloading Tangobos instead? So it's not clear what real benefit that would bring? However, it tends to imply the Tango folks would have to maintain that relationship "long-term" ... we already have more than enough on our plate as it is :) This does raise two items of interest: what does that "maintain" word mean with regard to Tango, and what does a PhanTango 'merger' actually mean to people ... 1. ------ We're always open to new and interesting functionality in Tango, but what's needed more than that is a commitment from the contributing author to potentially maintain that contribution (at least in the short term). In addition, the dsource project tango.scrapple is becoming populated with all kinds of Tango related goodies, so that's an alternate home for compatible code. This is a like a sort of holding-tank for code that could make it into the library proper, but is being tried on first, by the community, to see if it fits. Still, that code needs to be maintained also (as/if needed). Speaking of which, the owners of these packages obviously do maintain them: http://dsource.org/projects/tango/wiki/TangoUsers In short, a key aspect of the Tango and related functionality is an implicit "commitment to maintain". This has not been an issue for library contributions made thus far, however, the whole 'commitment' aspect is quite relevant to the topic at hand: e.g. Tangobos 2. ------ What it is that people *really* want out of the compatibility effort? To my knowledge nobody from the NG has articulated that yet, though the assertion has thus far been "the runtime, and object.d". The latter would provide compatibility for 'toString' and the GC, but there's a slew of other items to consider. We had expected to try and make the Exception hierarchy of Tango support the (much smaller) set of phobos exceptions, for a start. But what about Threads? Tango threading is quite different in both extent and implementation, and also supports Fibers. Taking all those into consideration (which we have) would provide a rudimentary level of compatibility, somewhat similar to Tangobos. Then there's the import-path to consider, which is quite different between Tango and Phobos. Moving along we could consider high-impact items such as I/O. Yet, such things are much more difficult to make compatible ... are those the kind of things people expect also? So perhaps the big question here is this: how, and to what depth, do people wish for a level of compatibility? For example, how much value is there if this code is portable: # void main() # { # auto x = new Object; # auto y = x.toString; # } but this code is not: # import tango.io.Stdout; # # void main() # { # auto x = new Object; # auto y = x.toString; # Stdout.println (y); # } and this code is not: # import tango.io.File; # # void main() # { # auto content = File("myfile").read; # } You might feel these are trivial differences and, indeed, those examples are deliberately chosen as superficially similar. As you might imagine, it becomes progressively harder to mask such differences the deeper one digs. Some have suggested essentially 'mounting' the Phobos API on top of the Tango model. That would work fine for almost everything but, again, it's a question of manpower and a long-term maintenance commitment (if someone is willing to take that on then, please, do stand up) Comments?
Oct 09 2007
next sibling parent reply BCS <ao pathlink.com> writes:
Reply to kris,

 What it is that people *really* want out of the compatibility effort?

I like the idea of having piles of cool functionality in Tango, but sometime I just want a free function that have a four line description than I can understand without having to think about it. What I would love to see is to have a tango.lite that have most of the more common (non-broken) parts of phobos in it. And I'm talking edit a pile of import names and your working compatibility. Anyway, that's my 1.5 cents (25% discount for low quality thinking)
Oct 09 2007
next sibling parent "Kris" <foo bar.com> writes:
Reply to BCS:

FWIW, free-function style is already in the works


"BCS" <ao pathlink.com> wrote in message 
news:ce0a33432466c8c9d8d41a82e95e news.digitalmars.com...
 Reply to kris,

 What it is that people *really* want out of the compatibility effort?

I like the idea of having piles of cool functionality in Tango, but sometime I just want a free function that have a four line description than I can understand without having to think about it. What I would love to see is to have a tango.lite that have most of the more common (non-broken) parts of phobos in it. And I'm talking edit a pile of import names and your working compatibility. Anyway, that's my 1.5 cents (25% discount for low quality thinking)

Oct 09 2007
prev sibling parent reply Don Clugston <dac nospam.com.au> writes:
BCS wrote:
 Reply to kris,
 
 What it is that people *really* want out of the compatibility effort?

I like the idea of having piles of cool functionality in Tango, but sometime I just want a free function that have a four line description than I can understand without having to think about it. What I would love to see is to have a tango.lite that have most of the more common (non-broken) parts of phobos in it.

Seems to me, that there are actually TWO phobos-es (phobi ?). There's "core phobos", (std.file, etc) which has the basic i/o. There's also "complete phobos" which includes some disorganised stuff which has far more limited appeal (std.openrj, std.base64, std.uri, etc). Seems to me that when people talk about phobos-vs-tango, it's core phobos which has the biggest appeal, and the extended phobos which is most disliked. Could phobos be trimmed down to this core set? (Make the extended phobos be available as a separate download, or at least clearly distinguished?)
Oct 09 2007
next sibling parent Alexander Panek <a.panek brainsware.org> writes:
Don Clugston wrote:
 Seems to me, that there are actually TWO phobos-es (phobi ?).
 There's "core phobos", (std.file, etc) which has the basic i/o.
 There's also "complete phobos" which includes some disorganised stuff 
 which has far more limited appeal (std.openrj, std.base64, std.uri, etc).
 Seems to me that when people talk about phobos-vs-tango, it's core 
 phobos which has the biggest appeal, and the extended phobos which is 
 most disliked.
 Could phobos be trimmed down to this core set?
 (Make the extended phobos be available as a separate download, or at 
 least clearly distinguished?)

I like that idea. This way a compatibility between Tango and the Phobos core would be easier to achieve, I suppose. Higher level stuff (like you said: std.openrj, std.base64, etc.) could as well be based on a compatibility layer that defines a standard interface for Threads, I/O & co that applies for both, Phobos' core and Tango's core. This could even open the possibility for other runtime libraries (on top of that layer) or runtime library replacements (GC, Threads, .. like Tango now) without losing compatibility.
Oct 10 2007
prev sibling parent reply Aarti_pl <aarti interia.pl> writes:
Don Clugston pisze:
 Seems to me, that there are actually TWO phobos-es (phobi ?).
 There's "core phobos", (std.file, etc) which has the basic i/o.
 There's also "complete phobos" which includes some disorganised stuff 
 which has far more limited appeal (std.openrj, std.base64, std.uri, etc).
 Seems to me that when people talk about phobos-vs-tango, it's core 
 phobos which has the biggest appeal, and the extended phobos which is 
 most disliked.
 Could phobos be trimmed down to this core set?
 (Make the extended phobos be available as a separate download, or at 
 least clearly distinguished?)

I was thinking about something similar also... Having in mind that there will be (unfortunately long) process of allowing Phobos & Tango coexist together I was thinking about positioning both libraries in a D landscape. --- As I see there is demand among people for two kind of libraries: - library for lower level stuff, which should be fast, simple, small, easy to learn and use. Possible applications: embedded devices, quick hacks, scripting, game's engines, kernel programming etc. - library for higher level stuff, which gives flexibility, encapsulation and easy way to work in big teams. Possible applications: desktop programs, advanced networking, distributed computing etc. --- That said, I see good place for both libraries here Phobos and Tango: - Phobos should do lower level stuff. Functionalities in Phobos which belongs to second group should be dropped from it. - Tango should do higher level stuff. Functionalities in Tango which belongs to first group should be dropped from it. There will be also probably few areas where functionality will be duplicated (e.g. writef() vc. Cout()), but I don't think it will be a problem for anyone. --- In such a scenario Tango could be also delivered packaged with compiler, but it would be not necessary to use it for writing simple applications (no code in Phobos calls Tango). When someone needs higher level functionality she can use Tango. When using Tango, probably Phobos will be necessary also (Tango libraries can call Phobos). To sum up: 1. Runtime (from Tango) - one library 2. Lower level stuff Phobos - second library 3. Higher level stuff Tango - third library Everything mentioned above packed with compiler in easily installable packages for Windows/Linux/MacOs. :-) Best Regards Marcin Kuszczak (aarti_pl - www.zapytajmnie.com)
Oct 10 2007
next sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Aarti_pl wrote:

 Don Clugston pisze:
 Seems to me, that there are actually TWO phobos-es (phobi ?).
 There's "core phobos", (std.file, etc) which has the basic i/o.
 There's also "complete phobos" which includes some disorganised stuff
 which has far more limited appeal (std.openrj, std.base64, std.uri, etc).
 Seems to me that when people talk about phobos-vs-tango, it's core
 phobos which has the biggest appeal, and the extended phobos which is
 most disliked.
 Could phobos be trimmed down to this core set?
 (Make the extended phobos be available as a separate download, or at
 least clearly distinguished?)

I was thinking about something similar also... Having in mind that there will be (unfortunately long) process of allowing Phobos & Tango coexist together I was thinking about positioning both libraries in a D landscape. --- As I see there is demand among people for two kind of libraries: - library for lower level stuff, which should be fast, simple, small, easy to learn and use. Possible applications: embedded devices, quick hacks, scripting, game's engines, kernel programming etc. - library for higher level stuff, which gives flexibility, encapsulation and easy way to work in big teams. Possible applications: desktop programs, advanced networking, distributed computing etc.

I highly disagree with the notion that there is any kind of sharp distinction between those two groups.
 
 ---
 
 That said, I see good place for both libraries here Phobos and Tango:
 - Phobos should do lower level stuff. Functionalities in Phobos which
 belongs to second group should be dropped from it.
 - Tango should do higher level stuff. Functionalities in Tango which
 belongs to first group should be dropped from it.

If both Phobos and Tango is part of the standard library, it would make sense to clean out duplicate functionality, but regarding what is there today, I would still use the "low-level" functionality of Tango, not Phobos. Biased, yes, but for a reason.
 ---
 
 In such a scenario Tango could be also delivered packaged with compiler,
 but it would be not necessary to use it for writing simple applications
 (no code in Phobos calls Tango). When someone needs higher level
 functionality she can use Tango. When using Tango, probably Phobos will
 be necessary also (Tango libraries can call Phobos).
 
 To sum up:
 1. Runtime (from Tango) - one library
 2. Lower level stuff Phobos - second library
 3. Higher level stuff Tango - third library
 
 Everything mentioned above packed with compiler in easily installable
 packages for Windows/Linux/MacOs. :-)

If you do a s/Phobos/Tango on your 3 points above, you have correctly summarized Tango :) -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Oct 10 2007
parent reply Aarti_pl <aarti interia.pl> writes:
Lars Ivar Igesund pisze:
 Aarti_pl wrote:
 
 Having in mind that there will be (unfortunately long) process of
 allowing Phobos & Tango coexist together I was thinking about
 positioning both libraries in a D landscape.

 ---

 As I see there is demand among people for two kind of libraries:

 - library for lower level stuff, which should be fast, simple, small,
 easy to learn and use. Possible applications: embedded devices, quick
 hacks, scripting, game's engines, kernel programming etc.

 - library for higher level stuff, which gives flexibility, encapsulation
 and easy way to work in big teams. Possible applications: desktop
 programs, advanced networking, distributed computing etc.

I highly disagree with the notion that there is any kind of sharp distinction between those two groups.

True. I didn't say that there is sharp distinction. :-)
 That said, I see good place for both libraries here Phobos and Tango:
 - Phobos should do lower level stuff. Functionalities in Phobos which
 belongs to second group should be dropped from it.
 - Tango should do higher level stuff. Functionalities in Tango which
 belongs to first group should be dropped from it.

If both Phobos and Tango is part of the standard library, it would make sense to clean out duplicate functionality, but regarding what is there today, I would still use the "low-level" functionality of Tango, not Phobos. Biased, yes, but for a reason.

Yes, but having overlapping functionality in both library would not be so bad. Especially when you could "merge" both libraries and allow to use them together. There is clearly a need for both style libraries, as there were quite a few votes supporting Phobos style. And Walter is not willing to drop Phobos in favor of Tango. (Probably just because he is supporting Phobos like style of standard library :-D)
 ---

 In such a scenario Tango could be also delivered packaged with compiler,
 but it would be not necessary to use it for writing simple applications
 (no code in Phobos calls Tango). When someone needs higher level
 functionality she can use Tango. When using Tango, probably Phobos will
 be necessary also (Tango libraries can call Phobos).

 To sum up:
 1. Runtime (from Tango) - one library
 2. Lower level stuff Phobos - second library
 3. Higher level stuff Tango - third library

 Everything mentioned above packed with compiler in easily installable
 packages for Windows/Linux/MacOs. :-)

If you do a s/Phobos/Tango on your 3 points above, you have correctly summarized Tango :)

:-) Probably few modules from Tango core could find its home in Phobos. You wrote also about free functions in Tango - it's basically style characterizing Phobos, so they could be also part of Phobos. BR Marcin Kuszczak (aarti_pl - www.zapytajmnie.com)
Oct 10 2007
parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Aarti_pl wrote:
 
 That said, I see good place for both libraries here Phobos and Tango:
 - Phobos should do lower level stuff. Functionalities in Phobos which
 belongs to second group should be dropped from it.
 - Tango should do higher level stuff. Functionalities in Tango which
 belongs to first group should be dropped from it.

If both Phobos and Tango is part of the standard library, it would make sense to clean out duplicate functionality, but regarding what is there today, I would still use the "low-level" functionality of Tango, not Phobos. Biased, yes, but for a reason.

Yes, but having overlapping functionality in both library would not be so bad. Especially when you could "merge" both libraries and allow to use them together. There is clearly a need for both style libraries, as there were quite a few votes supporting Phobos style.

Even if Tango has a different "style" than Phobos, that has never been the reason for Tango existing. Any such need (need for certain style) should be pretty artificial. API style shouldn't really matter when choosing a library until the point where it clearly is the only true difference and/or it really inhibits the usage, whether due to being badly designed or because it don't fit with other packages used.
 
 And Walter is not willing to drop Phobos in favor of Tango. (Probably
 just because he is supporting Phobos like style of standard library :-D)

Afaik, style is not at all the reasoning behind any such decision, even if Phobos' style probably is Walter's preference.
 
 ---

 In such a scenario Tango could be also delivered packaged with compiler,
 but it would be not necessary to use it for writing simple applications
 (no code in Phobos calls Tango). When someone needs higher level
 functionality she can use Tango. When using Tango, probably Phobos will
 be necessary also (Tango libraries can call Phobos).

 To sum up:
 1. Runtime (from Tango) - one library
 2. Lower level stuff Phobos - second library
 3. Higher level stuff Tango - third library

 Everything mentioned above packed with compiler in easily installable
 packages for Windows/Linux/MacOs. :-)

If you do a s/Phobos/Tango on your 3 points above, you have correctly summarized Tango :)

:-) Probably few modules from Tango core could find its home in Phobos. You wrote also about free functions in Tango - it's basically style characterizing Phobos, so they could be also part of Phobos.

The differences between Tango and Phobos is so much more than the style, still that seems to be the only thing people focus on when choosing Phobos ahead of Tango. The style reason is for some a reason to choose Tango ahead of Phobos, but it is usually different things (like performance, stability, support, etc). This is the reason for me not thinking that your proposed approach above immediately is a smart move. To clarify, the non-runtime part of Tango is likely to continue to exist forever (the forever of software and programming languages at least), because to me and at least a few others, there is no need for Phobos. One needs to assume that Tango and Phobos run on a common or compatible runtime, for the following to be true, so let's assume that; Why would anyone use any amount of time and effort to keep Tango code in Phobos synced with the original in Tango, when all you need to do is download Tango in addition to Phobos? Having some modules from Tango in Phobos, then downloading Tango (because you may also want to use some higher level features) could then result in breakage if Tango contains unsynced changes to the stuff in Phobos (note that this don't have to be public API changes if there are any kind of dependencies between Tango modules in Phobos). There are also other issues with such a setup related to mantainance, bugfixing and support in general for the code So in my view, any kind of merger is first (and possibly only) about runtime compatibility. If one is to merge everything in some way, it may, for mantainance reasons (less core functionality to mantain, but a lot of work to do the initial wrap), make sense to build one of the API's on top of the other. Building for instance Tango IO on top of Phobos don't make sense though (at least to me), as it would degrade performance. Doing the opposite, would probably create other subtle differences due to Phobos' IO going via the C runtime. Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Oct 10 2007
next sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
Lars Ivar Igesund wrote:
..
 Why would anyone use any amount of time and effort to keep Tango code in
 Phobos synced with the original in Tango, when all you need to do is
 download Tango in addition to Phobos? Having some modules from Tango in
 Phobos, then downloading Tango (because you may also want to use some
 higher level features) could then result in breakage if Tango contains
 unsynced changes to the stuff in Phobos (note that this don't have to be
 public API changes if there are any kind of dependencies between Tango
 modules in Phobos). There are also other issues with such a setup related
 to mantainance, bugfixing and support in general for the code
 
 So in my view, any kind of merger is first (and possibly only) about runtime
 compatibility. If one is to merge everything in some way, it may, for
 mantainance reasons (less core functionality to mantain, but a lot of work
 to do the initial wrap), make sense to build one of the API's on top of the
 other. Building for instance Tango IO on top of Phobos don't make sense
 though (at least to me), as it would degrade performance. Doing the
 opposite, would probably create other subtle differences due to Phobos' IO
 going via the C runtime.  

I agree with this stance. To make it explicit, I think compatibility is first and foremost needed to enable Tango users to link to Phobos libraries and vice versa (imo). To me, the most minimal to make this possible is also the most desirable. Granted, tangobos can be used for this purpose, though a more formal solution in the long run might inspire more confidence. Not really on topic, but related: it would be nice for Phobos to be enriched with whatever improvements Tango have made to important parts such as the runtime design and the threads implementation.
Oct 10 2007
prev sibling next sibling parent reply Aarti_pl <aarti interia.pl> writes:
Reply to Lars Ivar Igesund:

-----------

I decided to skip discussion before, as it seems you misinterpreted a 
little bit my intentions.

I am all for merging libraries, and just thinking about the best way to 
do it.

 From earlier discussions it seems that:
1. Runtime will be merged.
2. Other fundamental incompatibilities will be ironed out: 
Exception/Error, toString/toUtf8

That's ok.

After that point it will be possible to write programs, which will work 
on same runtime and use Tango as normal extension library.

But IMHO there will be still somewhat strange situation where 2 
libraries will pretend to be kind of standard. That will be not so bad 
as situation which we have currently. But with some coordination between 
Tango and Phobos it is possible to transform such a situation into real 
advantage.

Basically I am saying following:
1. Both libraries should be packed together with compiler (e.g. DMD). 
 From user point of view it will be one standard library logically 
divided into 2 parts.

2. They will still live in their own namespaces: Phobos = std, Tango = 
tango.

3. As I said in previous posts:

- Phobos should do lower level stuff. Functionalities in Phobos
which belongs to second group should be dropped from it. Library 
characteristics: for lower level stuff, which should be fast, simple, 
small, easy to learn and use. Possible applications: embedded devices, 
quick hacks, scripting, game's engines, kernel programming etc. Style of 
library: free functions, simple classes, consts...

- Tango should do higher level stuff. Functionalities in Tango which 
belongs to first group should be dropped (transferred to Phobos) from 
it. Library characterisctics: for higher level stuff, which gives 
flexibility, encapsulation and easy way to work in big teams. Possible 
applications: desktop programs, advanced networking, distributed 
computing etc. Style of library: classes, inheritance, interfaces...

- It is not necessary that Tango will relay on Phobos functionality, but 
it should be possible to make such dependencies.

- There will be probably overlapping *functionality* (not same 
classes/functions!) in both libraries. I am thinking e.g. about issue 
with writef and Cout - in this case I think both ways of doing output 
have strong supporters.

4. It seems that Phobos will also "live forever", so alternative is that 
  you will have whole Tango, and whole Phobos side by side, while it 
would be much better to have both libraries profiled a little bit. If 
such profiling will not happen, duplication of code will be much bigger, 
as anyone using Tango will be able also to use high-level stuff from 
Phobos, which probably is also in Tango.

I hope it clears my opinion a little bit. These are just few thoughts. 
That said I think it could be quite difficult to coordinate such a big 
projects as Tango and Phobos. But for sure it would be better for users...

Best Regards
Marcin Kuszczak
(aarti_pl - www.zapytajmnie.com)
Oct 10 2007
parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Aarti_pl wrote:

 Reply to Lars Ivar Igesund:
 
 -----------
 
 I decided to skip discussion before, as it seems you misinterpreted a
 little bit my intentions.

I don't think I did, at least this post didn't give me any other view on what you are saying. My problem is probably that you seem to imply that Phobos is better suited for what you call low-level functionality, whereas I think Tango is _at least_ equally well suited, and unlike Phobos, very well integrated with the higher level aspects of Tango (or the other way round). Thus I am of the opinion that if you use the higher level functionality of Tango, then you generally should also use the lower level functionality of Tango. There is no code in Tango that would benefit from being built on top of Phobos (as Kris said elsewhere in the thread), although there may be code there that may serve as a basis or inspiration for implementations in Tango. Indeed, there are modules present in both. These are generally fairly standalone modules though. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Oct 10 2007
parent reply Marcin Kuszczak <aarti_nospam please_interia.pl> writes:
Lars Ivar Igesund wrote:

 Aarti_pl wrote:
 
 Reply to Lars Ivar Igesund:
 
 -----------
 
 I decided to skip discussion before, as it seems you misinterpreted a
 little bit my intentions.

I don't think I did, at least this post didn't give me any other view on what you are saying. My problem is probably that you seem to imply that Phobos is better suited for what you call low-level functionality, whereas I think Tango is _at least_ equally well suited, and unlike Phobos, very well integrated with the higher level aspects of Tango (or the other way round). Thus I am of the opinion that if you use the higher level functionality of Tango, then you generally should also use the lower level functionality of Tango. There is no code in Tango that would benefit from being built on top of Phobos (as Kris said elsewhere in the thread), although there may be code there that may serve as a basis or inspiration for implementations in Tango. Indeed, there are modules present in both. These are generally fairly standalone modules though.

Thanks, I understand clearly (I hope) your point now. But I rather would like to accent that currently it seems, that you will have no choice: Tango *OR* Phobos. Phobos will stay, and because of that there will be people who will use both: Tango *AND* Phobs. Both libraries are addressed to same target audience - they compete with each other. IMHO this kind of competition in standard libraries is not best thing for *D community* (I am not trying to advocate Tango or Phobos). Some people will use only Phobos, some only Tango, but I think that most will use few modules from Tango and few from Phobos. This will cause big mess because of duplicated functionality in both libraries. Imagine big development team which work on single program. You will find everything in it, nevertheless of design rules. One will use Tango net package and another one std.socket. Dividing responsibilities between Phobos and Tango would be *Good Thing (tm)*. That was my main message, and I tried to suggest that setting some kind of usage policies for Tango and for Phobos would help community in general. -- Regards Marcin Kuszczak (Aarti_pl) ------------------------------------- Ask me why... I believe in Jesus - http://www.zapytajmnie.com (en/pl) Doost (port of few Boost libraries) - http://www.dsource.org/projects/doost/ -------------------------------------
Oct 10 2007
parent reply "Kris" <foo bar.com> writes:
"Marcin Kuszczak" <aarti_nospam please_interia.pl> wrote in message

 usage policies for Tango and for Phobos would help community in
 general.

Speaking of which, Tango exists to /help/ both the community and D progress. It wasn't written for a giggle or a lark, and has been a truly expensive proposition (in various ways) for several of those involved <g> When you step away from the hobbyist level, D would get nowhere fast without a broad and cohesive library. Tango is designed to be an answer to that, is generally delivering at this stage, and is set to blossom in the very near future (wait and see). A number of people feel that something (perhaps intangible?) is missing and we're trying to get a handle on that, while at the same time trying to figure out what people really expect from a phantango merger. What's important to me is this: if a merger does /not/ resolve the pain-points, then it would a worthless and expensive exercise. To qualify that we need to identify those pain points. That's what this thread is about, and I'd like everyone to toss something in the bucket. I mean, there are people here who claim to really dislike Tango. It would be really helpful if those folks could/would also chime in with what their specific dislikes are? Without that, we're kinda running around in the dark bumping into each other ...
Oct 10 2007
parent reply "Peter C. Chapin" <pchapin sover.net> writes:
Kris wrote:

 A number of people feel that something (perhaps 
 intangible?) is missing and we're trying to get a handle on that, while at 
 the same time trying to figure out what people really expect from a 
 phantango merger.

The main issue from my point of view is compatibility. Right now, as I understand it, if I build a D library on top of Phobos or Tango I exclude users of the other run time system from using my library. This state of affairs in THE pain point. You don't have this situation in any other well established language (that I know of), and it greatly inhibits my inclination toward building D libraries. I actually don't care about features, style, or documentation because I shouldn't have to care. I should be able to use a single interface to a run time system and know that my work can be used by "anyone" else (barring special purpose configurations). For example, if I write a library in C++ I can use the facilities described by the C++ standard and know that everyone else will have those facilities available. If I need a third party library X, I can document that dependency and reasonably ask my users to also provide X without disrupting whatever else they are doing. Because of the Phobos vs Tango business D is not like this, and that is the one and only problem from my point of view. Peter
Oct 11 2007
parent "Kris" <foo bar.com> writes:
Yes, thank you!

This is a really important point because, supposing the Runtime was 
compatible, Peter still would likely not be able to do what he wants 
(because the I/O would still be different, for example). His point is 
exactly why we're trying to get a handle on what people want/expect.

- Kris


"Peter C. Chapin" <pchapin sover.net> wrote in message 
news:fel1gp$v1j$1 digitalmars.com...
 Kris wrote:

 A number of people feel that something (perhaps
 intangible?) is missing and we're trying to get a handle on that, while 
 at
 the same time trying to figure out what people really expect from a
 phantango merger.

The main issue from my point of view is compatibility. Right now, as I understand it, if I build a D library on top of Phobos or Tango I exclude users of the other run time system from using my library. This state of affairs in THE pain point. You don't have this situation in any other well established language (that I know of), and it greatly inhibits my inclination toward building D libraries. I actually don't care about features, style, or documentation because I shouldn't have to care. I should be able to use a single interface to a run time system and know that my work can be used by "anyone" else (barring special purpose configurations). For example, if I write a library in C++ I can use the facilities described by the C++ standard and know that everyone else will have those facilities available. If I need a third party library X, I can document that dependency and reasonably ask my users to also provide X without disrupting whatever else they are doing. Because of the Phobos vs Tango business D is not like this, and that is the one and only problem from my point of view. Peter

Oct 11 2007
prev sibling parent reply Yigal Chripun <yigal100 gmail.com> writes:
Lars Ivar Igesund wrote:

 So in my view, any kind of merger is first (and possibly only) about runtime
 compatibility. If one is to merge everything in some way, it may, for
 mantainance reasons (less core functionality to mantain, but a lot of work
 to do the initial wrap), make sense to build one of the API's on top of the
 other. Building for instance Tango IO on top of Phobos don't make sense
 though (at least to me), as it would degrade performance. Doing the
 opposite, would probably create other subtle differences due to Phobos' IO
 going via the C runtime.  
 
 Lars Ivar Igesund
 blog at http://larsivi.net
 DSource, #d.tango & #D: larsivi
 Dancing the Tango

A question: is it a good thing that Phobos depends on the c runtime? I'm not sure but won't it be better if the future merged D standard library wouldn't need the c runtime at all? (less dependencies and maybe better performance?)
Oct 10 2007
next sibling parent reply BCS <BCS pathlink.com> writes:
Yigal Chripun wrote:
 Lars Ivar Igesund wrote:
 
 So in my view, any kind of merger is first (and possibly only) about 
 runtime
 compatibility. If one is to merge everything in some way, it may, for
 mantainance reasons (less core functionality to mantain, but a lot of 
 work
 to do the initial wrap), make sense to build one of the API's on top 
 of the
 other. Building for instance Tango IO on top of Phobos don't make sense
 though (at least to me), as it would degrade performance. Doing the
 opposite, would probably create other subtle differences due to 
 Phobos' IO
 going via the C runtime. 
 Lars Ivar Igesund
 blog at http://larsivi.net
 DSource, #d.tango & #D: larsivi
 Dancing the Tango

A question: is it a good thing that Phobos depends on the c runtime? I'm not sure but won't it be better if the future merged D standard library wouldn't need the c runtime at all? (less dependencies and maybe better performance?)

at a bare minimum, you will need the OS system call API. That (on most systems) is C. You can't completely divorce your self from C and there is a lot of good low level "paint on the metal" C code out there. D is not going to do better than that stuff so why not just use it.
Oct 10 2007
parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
BCS wrote:

 Yigal Chripun wrote:
 Lars Ivar Igesund wrote:
 
 So in my view, any kind of merger is first (and possibly only) about
 runtime
 compatibility. If one is to merge everything in some way, it may, for
 mantainance reasons (less core functionality to mantain, but a lot of
 work
 to do the initial wrap), make sense to build one of the API's on top
 of the
 other. Building for instance Tango IO on top of Phobos don't make sense
 though (at least to me), as it would degrade performance. Doing the
 opposite, would probably create other subtle differences due to
 Phobos' IO
 going via the C runtime.
 Lars Ivar Igesund
 blog at http://larsivi.net
 DSource, #d.tango & #D: larsivi
 Dancing the Tango

A question: is it a good thing that Phobos depends on the c runtime? I'm not sure but won't it be better if the future merged D standard library wouldn't need the c runtime at all? (less dependencies and maybe better performance?)

at a bare minimum, you will need the OS system call API. That (on most systems) is C. You can't completely divorce your self from C and there is a lot of good low level "paint on the metal" C code out there. D is not going to do better than that stuff so why not just use it.

Performance wise, Tango is doing better than the C runtime (or at least the combination of Phobos+C runtime) for the testcases we know of. That the OS uses C as an interface to it's syscalls is not a relevant point in this dicussion. Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Oct 11 2007
parent "Kris" <foo bar.com> writes:
"Lars Ivar Igesund" <larsivar igesund.net> wrote in message 
news:fekm1g$8f4$1 digitalmars.com...

 Performance wise, Tango is doing better than the C runtime (or at least 
 the
 combination of Phobos+C runtime) for the testcases we know of. That the OS
 uses C as an interface to it's syscalls is not a relevant point in this
 dicussion.

earlier tests indicate that D+Tango was (in some cases) twice as fast as the equivalent C program on Win32. You can only make so much out of that, but it's still useful to know.
Oct 11 2007
prev sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
Yigal Chripun wrote:

 Lars Ivar Igesund wrote:
 
 So in my view, any kind of merger is first (and possibly only) about
 runtime compatibility. If one is to merge everything in some way, it may,
 for mantainance reasons (less core functionality to mantain, but a lot of
 work to do the initial wrap), make sense to build one of the API's on top
 of the other. Building for instance Tango IO on top of Phobos don't make
 sense though (at least to me), as it would degrade performance. Doing the
 opposite, would probably create other subtle differences due to Phobos'
 IO going via the C runtime.
 
 Lars Ivar Igesund
 blog at http://larsivi.net
 DSource, #d.tango & #D: larsivi
 Dancing the Tango

A question: is it a good thing that Phobos depends on the c runtime? I'm not sure but won't it be better if the future merged D standard library wouldn't need the c runtime at all? (less dependencies and maybe better performance?)

Tango don't depend on the C runtime for those exact reasons, however there may be reasons for using it if interoperability with C libraries is an issue at some level. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Oct 11 2007
prev sibling parent reply "Kris" <foo bar.com> writes:
"Aarti_pl" <aarti interia.pl> wrote in message 
news:fei899$1a6c$1 digitalmars.com...
 As I see there is demand among people for two kind of libraries:

 - library for lower level stuff, which should be fast, simple, small, easy 
 to learn and use. Possible applications: embedded devices, quick hacks, 
 scripting, game's engines, kernel programming etc.

That's Tango :)
 - library for higher level stuff, which gives flexibility, encapsulation 
 and easy way to work in big teams. Possible applications: desktop 
 programs, advanced networking, distributed computing etc.

That's Tango :)
 That said, I see good place for both libraries here Phobos and Tango:
 - Phobos should do lower level stuff. Functionalities in Phobos which 
 belongs to second group should be dropped from it.

And that's where the misconception comes in. The benefits in the high level of Tango are often based upon the capabilities in the "lower" levels. Which is why the earlier question had been posed about Tango I/O. You don't get Tango without the I/O package, because that is one of the definitive differences between the two libraries. In short, there's nothing in Phobos that Tango would benefit from. When it comes to I/O, for example, Tango seriously outperforms every other library we've bothered to test. When it comes to string processing, the same is true. This is due to the design of Tango.
 - Tango should do higher level stuff. Functionalities in Tango which 
 belongs to first group should be dropped from it.

Tango did not evolve in a vacuum ... it took all the things that were "wrong" with phobos and fixed them, so you can't revert some of that and hope to gain anything useful :)
 To sum up:
 1. Runtime (from Tango) - one library
 2. Lower level stuff Phobos - second library
 3. Higher level stuff Tango - third library

You're talking about Tango, all by itself :) Perhaps another way to ask these questions might be this: what type/style of phobos functionlaity would you like to see in Tango? BCS hinted at this early on, and it would be useful to hear more of that ... - Kris
Oct 10 2007
next sibling parent reply 0ffh <spam frankhirsch.net> writes:
Kris wrote:
 Perhaps another way to ask these questions might be this:  what type/style 
 of phobos functionlaity would you like to see in Tango?  BCS hinted at this 
 early on, and it would be useful to hear more of that ...

What I like most about Phobos is it's ease-of-use and it's style. I know you are already working on stand-alone functions in Tango, and it's a good thing to do, IMHO. :) Regards, Frank
Oct 10 2007
next sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
0ffh wrote:

 Kris wrote:
 Perhaps another way to ask these questions might be this:  what
 type/style
 of phobos functionlaity would you like to see in Tango?  BCS hinted at
 this early on, and it would be useful to hear more of that ...

What I like most about Phobos is it's ease-of-use and it's style.

That you like the style is a fair point, but as I mentioned elsewhere, I think that generally should be a secondary consideration. ease-of-use however should be much more important. So my question is, does Phobos' style make it easier for you to use? Is this due to free standing functions, or because Phobos has few modules to search through? If the latter, would a different type of docs, showing where to find functionality in Tango, be of help?
 I know you are already working on stand-alone functions in Tango,
 and it's a good thing to do, IMHO. :)

It is not as if such functions are non-existant in Tango, so which exact functionality do you think is better expressed through free standing functions rather than objects? The answers of others shows that this usually is wanted for objects where you often need only one operation on the given object, even if others are available. This don't remove the fact that an object (class) equally often is a useful abstraction, and when that is established, free standing functions usually should be implemented as wrappers around each method on the object, rather than the object being implemented via free standing functions. This is why Tango looks as it does today; we have avoided wrappers of our own code if possible, because they degrade orthogonality of the API, and add more code to maintain. Whether we have been to strict in enforcing that stance, is an open question.
 
 Regards, Frank

-- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Oct 10 2007
parent reply BCS <BCS pathlink.com> writes:
Lars Ivar Igesund wrote:
 0ffh wrote:
 
 
Kris wrote:

Perhaps another way to ask these questions might be this:  what
type/style
of phobos functionlaity would you like to see in Tango?  BCS hinted at
this early on, and it would be useful to hear more of that ...

What I like most about Phobos is it's ease-of-use and it's style.

That you like the style is a fair point, but as I mentioned elsewhere, I think that generally should be a secondary consideration. ease-of-use however should be much more important. So my question is, does Phobos' style make it easier for you to use? Is this due to free standing functions, or because Phobos has few modules to search through? If the latter, would a different type of docs, showing where to find functionality in Tango, be of help?

I think that style and ease of use are tightly linked. In Phobos, if you want to write to the screen you use writef and it dumps a pile of stuff to the screen. In tango (from what I've seen) you get a reference to an object and then run a big sequence of chained calls. In some cases, the tango way has something going for it, but in others, Just get the ___ out of my way and put "bla bla bla" on the screen. I don't care if it's less flexible, because I just want to print. This may be a bit overreacting but it's similar for Phobos's streams and whatever Tango has. Last time I had time to try to learn tango's IO, I spent about 2 hours trying to get my head around how the heck it worked and still I couldn't figure it out (this might have been a side effect of me trying to get a 500 ft. overview of how the whole thing works and not just a cookbook do ABC to get XYZ understanding). In Phobos, there are streams, you can read from them with a few dozen methods and write to them with about the same. Everything you need to know you can get in about 5 screens of web page that is mostly a list of nearly identical functions.
 
I know you are already working on stand-alone functions in Tango,
and it's a good thing to do, IMHO. :)

It is not as if such functions are non-existant in Tango, so which exact functionality do you think is better expressed through free standing functions rather than objects? The answers of others shows that this usually is wanted for objects where you often need only one operation on the given object, even if others are available. This don't remove the fact that an object (class) equally often is a useful abstraction, and when that is established, free standing functions usually should be implemented as wrappers around each method on the object, rather than the object being implemented via free standing functions. This is why Tango looks as it does today; we have avoided wrappers of our own code if possible, because they degrade orthogonality of the API, and add more code to maintain. Whether we have been to strict in enforcing that stance, is an open question.

Where the "OO is god" (oops, make that "good") stance puts me off is where it get in my way with things like (random example) RegEx. I don't want to new of an object and fill in all the members (etc, etc) just to run one regex match and then drop the object. I'd love to have both a RegEx class then compiles to some sort of fast state machine and a free function that does an on the fly interpretation. Before you even say it; That is a totally impractical way to do it. Why have two totally independent code bases doing (almost) exactly the same thing? At this point I'm just stating what I think would be ideal, not what I expect to get. I know that's all a bit disjointed, but I hope it shows something of my reservations of switching to Tango.
 
Regards, Frank


Oct 10 2007
next sibling parent reply Yigal Chripun <yigal100 gmail.com> writes:
BCS wrote:
 
 Where the "OO is god" (oops, make that "good") stance puts me off is 
 where it get in my way with things like (random example) RegEx. I don't 
 want to new of an object and fill in all the members (etc, etc) just to 
 run one regex match and then drop the object. I'd love to have both a 
 RegEx class then compiles to some sort of fast state machine and a free 
 function that does an on the fly interpretation.
 
 Before you even say it; That is a totally impractical way to do it. Why 
 have two totally independent code bases doing (almost) exactly the same 
 thing? At this point I'm just stating what I think would be ideal, not 
 what I expect to get.
 
 
 I know that's all a bit disjointed, but I hope it shows something of my 
 reservations of switching to Tango.
 

if i understand you correctly what you ask for is an implementation of regEx as in Ruby. Ruby is totally OOP and RegEx is OOP based so we have classes an such to represent the expression and the results, etc.. on top of it it implement an interface wich allows you to use regEx as you would normally expect (like in perl. for example you can use literal expressions like /pattern/). most of the time people use that. you can use the underlying classes if you want but that of course is more verbose (and probably most of the time is not needed). This is much better than two code bases, it gives us the benefits of both styles and i think that's what lars suggests. the only thing left to do is figure out how a similar structure could be implemented in D.
Oct 10 2007
parent BCS <BCS pathlink.com> writes:
Yigal Chripun wrote:
 BCS wrote:
 
 Where the "OO is god" (oops, make that "good") stance puts me off is 
 where it get in my way with things like (random example) RegEx. I 
 don't want to new of an object and fill in all the members (etc, etc) 
 just to run one regex match and then drop the object. I'd love to have 
 both a RegEx class then compiles to some sort of fast state machine 
 and a free function that does an on the fly interpretation.

 Before you even say it; That is a totally impractical way to do it. 
 Why have two totally independent code bases doing (almost) exactly the 
 same thing? At this point I'm just stating what I think would be 
 ideal, not what I expect to get.


 I know that's all a bit disjointed, but I hope it shows something of 
 my reservations of switching to Tango.

if i understand you correctly what you ask for is an implementation of regEx as in Ruby. Ruby is totally OOP and RegEx is OOP based so we have classes an such to represent the expression and the results, etc.. on top of it it implement an interface wich allows you to use regEx as you would normally expect (like in perl. for example you can use literal expressions like /pattern/). most of the time people use that. you can use the underlying classes if you want but that of course is more verbose (and probably most of the time is not needed). This is much better than two code bases, it gives us the benefits of both styles and i think that's what lars suggests. the only thing left to do is figure out how a similar structure could be implemented in D.

Actually what I want (and don't expect to get) is two independent implementation of RegEx. One would be OO the other would not share code with the OO version. The point is that the OO version will probably have a RegEx compiler in the constructor that has a time and memory cost on the assumption that you will use the RegEx several times and the improved match performance will recoup that. OTOH the free function one would not compile the RegEx. Rather it would interpret the string it's self and compare it to the text /as/ it reads though the pattern. The assumption here bing that many regex are simple and used once and that the fastest way to match them is to avoid overhead like the plague. again I'm not arguing for this, just stating one case where "style" makes a difference
Oct 10 2007
prev sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Generally I think you make a comment on an uninformed basis, but I'll try to
put you straight :)

BCS wrote:

 Lars Ivar Igesund wrote:
 0ffh wrote:
 
 
Kris wrote:

Perhaps another way to ask these questions might be this:  what
type/style
of phobos functionlaity would you like to see in Tango?  BCS hinted at
this early on, and it would be useful to hear more of that ...

What I like most about Phobos is it's ease-of-use and it's style.

That you like the style is a fair point, but as I mentioned elsewhere, I think that generally should be a secondary consideration. ease-of-use however should be much more important. So my question is, does Phobos' style make it easier for you to use? Is this due to free standing functions, or because Phobos has few modules to search through? If the latter, would a different type of docs, showing where to find functionality in Tango, be of help?

I think that style and ease of use are tightly linked. In Phobos, if you want to write to the screen you use writef and it dumps a pile of stuff to the screen. In tango (from what I've seen) you get a reference to an object and then run a big sequence of chained calls. In some cases, the tango way has something going for it, but in others, Just get the ___ out of my way and put "bla bla bla" on the screen. I don't care if it's less flexible, because I just want to print.

How on earth is Cout("somestring"); more "complex" than writef (write actually)? You can use chained calls with Tango, but you don't have to, and generally you won't. So Tango is probably both flexible _and_ able to do just do what you want?
 
 This may be a bit overreacting but it's similar for Phobos's streams and
 whatever Tango has. Last time I had time to try to learn tango's IO, I
 spent about 2 hours trying to get my head around how the heck it worked
 and still I couldn't figure it out (this might have been a side effect
 of me trying to get a 500 ft. overview of how the whole thing works and
 not just a cookbook do ABC to get XYZ understanding). In Phobos, there
 are streams, you can read from them with a few dozen methods and write
 to them with about the same. Everything you need to know you can get in
 about 5 screens of web page that is mostly a list of nearly identical
 functions.

Tango's IO system is indeed flexible, and to some complex to learn. With the fairly new stream abstractions, it should be no more difficult than Phobos' though, and indeed, in Tango they are integrated such that you can chain streams using them as filters and more.
 
 
 
I know you are already working on stand-alone functions in Tango,
and it's a good thing to do, IMHO. :)

It is not as if such functions are non-existant in Tango, so which exact functionality do you think is better expressed through free standing functions rather than objects? The answers of others shows that this usually is wanted for objects where you often need only one operation on the given object, even if others are available. This don't remove the fact that an object (class) equally often is a useful abstraction, and when that is established, free standing functions usually should be implemented as wrappers around each method on the object, rather than the object being implemented via free standing functions. This is why Tango looks as it does today; we have avoided wrappers of our own code if possible, because they degrade orthogonality of the API, and add more code to maintain. Whether we have been to strict in enforcing that stance, is an open question.

Where the "OO is god" (oops, make that "good") stance puts me off is where it get in my way with things like (random example) RegEx. I don't want to new of an object and fill in all the members (etc, etc) just to run one regex match and then drop the object. I'd love to have both a RegEx class then compiles to some sort of fast state machine and a free function that does an on the fly interpretation.

I highly doubt this is a good example from Tango considering Tango and Phobos currently share Regex implementation?
 I know that's all a bit disjointed, but I hope it shows something of my
 reservations of switching to Tango.

It mostly shows that you are making decisions on an uninformed and outdated basis :) -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Oct 11 2007
next sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
Lars Ivar Igesund wrote:

 Generally I think you make a comment on an uninformed basis, but I'll try
 to put you straight :)

Just noted that the post elsewhere in the thread was much more useful :) Thanks! -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Oct 11 2007
prev sibling next sibling parent reply Chad J <gamerChad _spamIsBad_gmail.com> writes:
Lars Ivar Igesund wrote:
 
 How on earth is
 
 Cout("somestring"); more "complex" than writef (write actually)?
 

ooo, something I have issue with... Cout doesn't do formatting. Stdout doesn't do formatting. So writefln("number: %d", number); becomes Stdout.formatln("number: {0}", number); Why doesn't plain Stdout do this? Oh, and even if it did, Stdout("number: {0}", number); would not insert a newline. I have to use Stdout("number: {0}", number).newline; instead, which is again more typing. I have to type this stuff a lot, so I'd like it to be easy. It would be really nice to have Stdout("number: {0}", number).nl; // .nl for "newline" or .ln for "line" as a start. Shorthand is useful in some cases. It would be straight awesome to have Stdout("Point(op1[{0},{1},{2}],",x,y,z)("op2[{0},{1},{2}])",t,u,v).nl; It also scales nicely. You don't need to understand the above line to write a simple Stdout("Hello world!");. As I understand it, Cout is a bit more lightweight or somesuch, so I don't really have any issues with it, other than that maybe it should be hidden away as something only experienced tango users should play with as a means of optimizing their programs. Text output seems easy enough to generalize, so in that case just stick to one /single/ canonical way of doing it that works really well and scales.
Oct 11 2007
parent BCS <ao pathlink.com> writes:
Reply to Chad,

 Lars Ivar Igesund wrote:
 
 How on earth is
 
 Cout("somestring"); more "complex" than writef (write actually)?
 

Cout doesn't do formatting. Stdout doesn't do formatting. So writefln("number: %d", number); becomes Stdout.formatln("number: {0}", number); Why doesn't plain Stdout do this? Oh, and even if it did, Stdout("number: {0}", number); would not insert a newline. I have to use Stdout("number: {0}", number).newline; instead, which is again more typing. I have to type this stuff a lot, so I'd like it to be easy. It would be really nice to have Stdout("number: {0}", number).nl; // .nl for "newline" or .ln for "line" as a start. Shorthand is useful in some cases. It would be straight awesome to have Stdout("Point(op1[{0},{1},{2}],",x,y,z)("op2[{0},{1},{2}])",t,u,v).nl; It also scales nicely. You don't need to understand the above line to write a simple Stdout("Hello world!");. As I understand it, Cout is a bit more lightweight or somesuch, so I don't really have any issues with it, other than that maybe it should be hidden away as something only experienced tango users should play with as a means of optimizing their programs. Text output seems easy enough to generalize, so in that case just stick to one /single/ canonical way of doing it that works really well and scales.

gneralIdea.votes++; Give the chained calls overload with formatting directives
Oct 11 2007
prev sibling next sibling parent reply BCS <ao pathlink.com> writes:
Reply to Lars,

 Generally I think you make a comment on an uninformed basis, but I'll
 try to put you straight :)
 
 BCS wrote:
 
 I think that style and ease of use are tightly linked. In Phobos, if
 you want to write to the screen you use writef and it dumps a pile of
 stuff to the screen. In tango (from what I've seen) you get a
 reference to an object and then run a big sequence of chained calls.
 In some cases, the tango way has something going for it, but in
 others, Just get the ___ out of my way and put "bla bla bla" on the
 screen. I don't care if it's less flexible, because I just want to
 print.
 

Cout("somestring"); more "complex" than writef (write actually)?

it isn't, but what about writef("hello %s, how did you like your %d, %s?", name, count, product); vs. Cout("hello ")(name)(", how did you like your ")(count)(", ")(product)("?"); The first is one (static) function call, the other is 7 (virtual) function calls, to 3 different functions. If you don't see a difference in complexity, then you are measuring something different than me. Note: there may be a better way to do that, but I don't know what it is.
 You can use chained calls with Tango, but you don't have to, and
 generally you won't. So Tango is probably both flexible _and_ able to
 do just do what you want?
 

I'm a cycle snob. How hard it is to code, how hard it is to get it to do what I want and *how long it takes to run* are of equal importance to me. With tango's use of chained calls (not exactly free from a performance standpoint) is a small minus in my book.
 Tango's IO system is indeed flexible, and to some complex to learn.
 With the fairly new stream abstractions, it should be no more
 difficult than Phobos' though, and indeed, in Tango they are
 integrated such that you can chain streams using them as filters and
 more.

please don't waste your time here explaining to me how it work. Please do put the same amount of time into improving the docs so that everyone can get the benefit.
 Where the "OO is god" (oops, make that "good") stance puts me off is
 where it get in my way with things like (random example) RegEx. I
 don't want to new of an object and fill in all the members (etc, etc)
 just to run one regex match and then drop the object. I'd love to
 have both a RegEx class then compiles to some sort of fast state
 machine and a free function that does an on the fly interpretation.
 

Phobos currently share Regex implementation?

Well, I'm not to fond of it as part of phobos ether. My point was an example of where "style" is more than a secondary concern.
 I know that's all a bit disjointed, but I hope it shows something of
 my reservations of switching to Tango.
 

uninformed and

wrong*
 outdated 

correct
 basis :)

If these thing have changed, I'm happy for Tango. Don't get me wrong, I want to use Tango, It's just that the benefit has yet to outweigh the cost, primarily as a result of a dwindling supply of my available time. * it is not uninformed because I knew it is outdated. Also, the decisions you mention are "tango /was/ to complex for me to learn /in the time I had/" and "I don't have time to figure out Tango now". Even with world class docs, I wouldn't have the time now. One of my jobs might be going into a project In D and that would let me /make/ the time to figure it out. But at this point, I booked for most of the time I'm awake
Oct 11 2007
parent reply "Kris" <foo bar.com> writes:
"BCS" <ao pathlink.com> wrote in message

[snip]

 I'm a cycle snob. How hard it is to code, how hard it is to get it to do 
 what I want and *how long it takes to run* are of equal importance to me. 
 With tango's use of chained calls (not exactly free from a performance 
 standpoint) is a small minus in my book.

This is worth discussing, since I'm sometimes a cycle-snob also :) Chained calls actually cost /less/, since the dispatch is decided at compile-time rather than runtime. In other words, chained-calls don't have to go through a big switch statement to figure out the type and dispatch based upon that. Thus, purely from a runtime cycle-count, chained calls really /are/ more efficient (for the kind of thing we are talking about). This is one of the reasons why Tango uses chained calls in some aspects of the IO model. :p
Oct 11 2007
parent reply BCS <ao pathlink.com> writes:
Reply to kris,

 "BCS" <ao pathlink.com> wrote in message
 
 [snip]
 
 I'm a cycle snob. How hard it is to code, how hard it is to get it to
 do what I want and *how long it takes to run* are of equal importance
 to me. With tango's use of chained calls (not exactly free from a
 performance standpoint) is a small minus in my book.
 

Chained calls actually cost /less/, since the dispatch is decided at compile-time rather than runtime. In other words, chained-calls don't have to go through a big switch statement to figure out the type and dispatch based upon that. Thus, purely from a runtime cycle-count, chained calls really /are/ more efficient (for the kind of thing we are talking about). This is one of the reasons why Tango uses chained calls in some aspects of the IO model. :p

interesting. I would say this indicates a defect in something. Either the implementation of switch or the TypeInfo stuff. The number of different choices that writef has to chouse from is only around a dozen or so. I would expect that the compiler should be able to get that switch down to a few ops and a table lookup. BTW how does DMD implement switches for integers? some sort of perfect hash generator and a table lookup?
Oct 11 2007
parent Jari-Matti =?ISO-8859-1?Q?M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
BCS wrote:
 Reply to kris,

 Chained calls actually cost /less/, since the dispatch is decided at
 compile-time rather than runtime. In other words, chained-calls don't
 have to go through a big switch statement to figure out the type and
 dispatch based upon that. Thus, purely from a runtime cycle-count,
 chained calls really /are/ more efficient (for the kind of thing we
 are talking about). This is one of the reasons why Tango uses chained
 calls in some aspects of the IO model.
 
 :p
 

interesting. I would say this indicates a defect in something. Either the implementation of switch or the TypeInfo stuff. The number of different choices that writef has to chouse from is only around a dozen or so. I would expect that the compiler should be able to get that switch down to a few ops and a table lookup. BTW how does DMD implement switches for integers? some sort of perfect hash generator and a table lookup?

I think Kris was pointing out that the runtime needs to parse the format string, but with chained calls there is a possibility to statically dispatch in many cases - of course e.g. OOP polymorphism still needs normal runtime lookups.
Oct 13 2007
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
Anders Bergh wrote:
 On 10/11/07, Lars Ivar Igesund <larsivar igesund.net> wrote:
 How on earth is

 Cout("somestring"); more "complex" than writef (write actually)?

Upper-case "C"...

I don't like that either :-) I think it's an artifact of earlier design iterations. Sean
Oct 11 2007
parent reply Christopher Wright <dhasenan gmail.com> writes:
Sean Kelly wrote:
 Anders Bergh wrote:
 On 10/11/07, Lars Ivar Igesund <larsivar igesund.net> wrote:
 How on earth is

 Cout("somestring"); more "complex" than writef (write actually)?

Upper-case "C"...

I don't like that either :-) I think it's an artifact of earlier design iterations. Sean

Then you could add "alias Cout cout", I guess. Anything preventing that?
Oct 11 2007
next sibling parent BCS <ao pathlink.com> writes:
Reply to Christopher,

 Sean Kelly wrote:
 
 Anders Bergh wrote:
 
 On 10/11/07, Lars Ivar Igesund <larsivar igesund.net> wrote:
 
 How on earth is
 
 Cout("somestring"); more "complex" than writef (write actually)?
 


design iterations. Sean

that?

have you over used: #define BEGIN { #define END } ? <G>
Oct 11 2007
prev sibling parent reply Chad J <gamerChad _spamIsBad_gmail.com> writes:
Christopher Wright wrote:
 Sean Kelly wrote:
 Anders Bergh wrote:
 On 10/11/07, Lars Ivar Igesund <larsivar igesund.net> wrote:
 How on earth is

 Cout("somestring"); more "complex" than writef (write actually)?

Upper-case "C"...

I don't like that either :-) I think it's an artifact of earlier design iterations. Sean

Then you could add "alias Cout cout", I guess. Anything preventing that?

afaik, you can't import aliases. So that alias would only apply to the file it's in, not to the user file importing it. You could just ...rename it... ;) I would actually appreciate a library willing to modify and deprecate stuff to get rid of old idiosyncrasies.
Oct 11 2007
next sibling parent reply BCS <ao pathlink.com> writes:
Reply to Chad,

 Christopher Wright wrote:
 
 Sean Kelly wrote:
 
 Anders Bergh wrote:
 
 On 10/11/07, Lars Ivar Igesund <larsivar igesund.net> wrote:
 
 How on earth is
 
 Cout("somestring"); more "complex" than writef (write actually)?
 


design iterations. Sean

that?

the file it's in, not to the user file importing it. You could just ...rename it... ;) I would actually appreciate a library willing to modify and deprecate stuff to get rid of old idiosyncrasies.

I think you can uses aliases in other files.
Oct 11 2007
parent reply Chad J <gamerChad _spamIsBad_gmail.com> writes:
BCS wrote:
 
 I think you can uses aliases in other files.
 
 

I just tested it, and apparently I'm wrong. In fact, I'm glad I'm wrong. I think I know what the snag was now. Something to the opposite effect. Aliases can't be hidden at a module level, even by private. // imp.d private alias int Foo; // main.d import imp; void main() { Foo bar = 3; } // Compiles and runs. Interestingly, aliases can be hidden by placing them in other constructs. Just change imp.d to the following: //imp.d private struct Baz { alias int Foo; Foo member; } Then the desired compile failure happens. Even so, it can be circumvented by writing Baz.Foo in main(). Given this cursory inspection, it seems that there is no way to completely hide aliases. I'm not sure how I feel about that.
Oct 11 2007
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Chad J wrote:
 BCS wrote:
 I think you can uses aliases in other files.

I just tested it, and apparently I'm wrong. In fact, I'm glad I'm wrong. I think I know what the snag was now. Something to the opposite effect. Aliases can't be hidden at a module level, even by private. // imp.d private alias int Foo; // main.d import imp; void main() { Foo bar = 3; } // Compiles and runs. Interestingly, aliases can be hidden by placing them in other constructs. Just change imp.d to the following: //imp.d private struct Baz { alias int Foo; Foo member; } Then the desired compile failure happens. Even so, it can be circumvented by writing Baz.Foo in main(). Given this cursory inspection, it seems that there is no way to completely hide aliases. I'm not sure how I feel about that.

I'm very sure how I feel about that. It's a bug. Anyone know if it's been filed? --bb
Oct 11 2007
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
Chad J wrote:
 Christopher Wright wrote:
 Sean Kelly wrote:
 Anders Bergh wrote:
 On 10/11/07, Lars Ivar Igesund <larsivar igesund.net> wrote:
 How on earth is

 Cout("somestring"); more "complex" than writef (write actually)?

Upper-case "C"...

I don't like that either :-) I think it's an artifact of earlier design iterations.

Then you could add "alias Cout cout", I guess. Anything preventing that?

afaik, you can't import aliases. So that alias would only apply to the file it's in, not to the user file importing it. You could just ...rename it... ;) I would actually appreciate a library willing to modify and deprecate stuff to get rid of old idiosyncrasies.

Kris explained this one to me. Global singletons are declared in CamelCase to both identify them and to reduce the chance of collisions with local variables. But I don't like that it's inconsistent with other variable declarations and I'm not sure name collisions would be an issue anyway. So YMMV. As an aside though, if the CamelCase convention were dropped, we may need a different name for Stdout, since it would collide with the C symbol of the same name. Sean
Oct 11 2007
parent Walter Bright <newshound1 digitalmars.com> writes:
Sean Kelly wrote:
 Kris explained this one to me.  Global singletons are declared in 
 CamelCase to both identify them and to reduce the chance of collisions 
 with local variables.

Just use one letter variable names for locals, and you're golden :-)
Oct 11 2007
prev sibling parent reply "Kris" <foo bar.com> writes:
"0ffh" <spam frankhirsch.net> wrote in message 
news:fej1ad$30el$1 digitalmars.com...
 Kris wrote:
 Perhaps another way to ask these questions might be this:  what 
 type/style of phobos functionlaity would you like to see in Tango?  BCS 
 hinted at this early on, and it would be useful to hear more of that ...

What I like most about Phobos is it's ease-of-use and it's style. I know you are already working on stand-alone functions in Tango, and it's a good thing to do, IMHO. :) Regards, Frank

Thanks, Frank. If you could be specific about some of those, it would help notably ... can you provide an example or two, please?
Oct 10 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Kris wrote:
 "0ffh" <spam frankhirsch.net> wrote in message 
 news:fej1ad$30el$1 digitalmars.com...
 Kris wrote:
 Perhaps another way to ask these questions might be this:  what 
 type/style of phobos functionlaity would you like to see in Tango?  BCS 
 hinted at this early on, and it would be useful to hear more of that ...

I know you are already working on stand-alone functions in Tango, and it's a good thing to do, IMHO. :) Regards, Frank

Thanks, Frank. If you could be specific about some of those, it would help notably ... can you provide an example or two, please?

Ideally, tango would just be a library I could import like any other. But assuming that's not going to happen, here's what I think could make the schism easier to deal with. *** Convenience functions *** Here's a list of things I actually use frequently in phobos, ordered roughly by frequency of use: std.stdio : writef,writefln std.string : format std.math std.conv std.regexp std.path std.stream : BufferedFile std.file : exists,isFile,isDir If there were equivalently easy-to-use versions of those in Tango, that would cover my uses. And maybe there are already for some, but i see for example that std.path is replaced by a cumbersome OO interface, and std.conv has no recommended equivalent. [http://www.dsource.org/projects/tango/wiki/PhobosTangoMigration] Anyway, to use anything beyond those few up there (and even some of those) I have to look up what the API is on the web page. BUT one advantage of Phobos there, is that I can find anything I need pretty quickly with that list of modules on the left hand side of the Phobos page. *** Better API documentation *** In contrast, the closest thing with Tango seems to be the Tango API Index (http://www.dsource.org/projects/tango/docs/current/) which has a huge list of names of everything in Tango, much of which is implementation detail users shouldn't be mucking with. So it's hard to find the thing you're looking for if you just want to know how to open a file. I think a simplified module index that omits things users won't generally need would help on that front. And a one-line description next to each link wouldn't hurt either. Topical groupings might help too. Like have a list of every module related to "Text Processing" "Networking". The categories in the reference manual might be a good place to start. Another Tango doc gripe is that the modules don't have any useful module-level descriptions. Look at phobos' std.conv for comparison: http://www.digitalmars.com/d/1.0/phobos/std_conv.html The page starts off with a useful description of what std.conv is for. Given that, I can quickly tell if std.conv is the right module for the job or not (as in it provides atoi and atol type conversions, rather than being a module for doing temperature conversions or image convolutions or something). Other modules in Phobos are even better, like std.boxer, giving both a quick overview *and* a few basic usage examples. *** Easier switching back and forth *** It seems that installing Tango itself is pretty easy now, at least if you have dsss installed, but AFAIK that renders all your phobos-based libs useless. Tango should do two things to make switching back and forth easier. 1) Tanogobos should be a part of the default install 2) A solution for tango-phobos switching should be installed by default. I don't care how it's done but I think it should come in two flavors: a) a per-shell transient method for changing the default b) a global per-installation (or per-user if there's some way to get that) method. As someone who still has a lot of code written that depends on Phobos, I want to know that I can go back and forth between Phobos and Tango easily. Right now if I want to install Tango and still use Phobos occasionally, I have to choose between three different fiddly techniques (http://www.dsource.org/projects/tango/wiki/PhobosTangoCooperation). The web page gives no reason to prefer one method over another, so that means I have to read all three and understand how they work well enough to determine which method is the best for me. Something like this should just happen automatically as a part of installing Tango. If I'm going to write a library that depends on Tango, I want to be able to say to potential users that all they have to do to use it is: """ 1) Install tango (dsss net install tango). 2) Type the command "set_dlibrary tango"[*] at a command prompt. and later 3) if you need to go back to Phobos type "set_dlibrary phobos"[*] [*] To make the switch persistent use "set_dlibrary -p" """ Achieving this level of simplicity probably requires some cooperation from Walter. But it seems utterly attainable. Unlike merging the runtimes. --bb
Oct 10 2007
next sibling parent "Kris" <foo bar.com> writes:
Nice! Thanks for this. Some comments inline:


"Bill Baxter" <dnewsgroup billbaxter.com> wrote in message 
news:fek90r$2e9o$1 digitalmars.com...
 Kris wrote:
 "0ffh" <spam frankhirsch.net> wrote in message 
 news:fej1ad$30el$1 digitalmars.com...
 Kris wrote:
 Perhaps another way to ask these questions might be this:  what 
 type/style of phobos functionlaity would you like to see in Tango?  BCS 
 hinted at this early on, and it would be useful to hear more of that 
 ...

I know you are already working on stand-alone functions in Tango, and it's a good thing to do, IMHO. :) Regards, Frank

Thanks, Frank. If you could be specific about some of those, it would help notably ... can you provide an example or two, please?

Ideally, tango would just be a library I could import like any other. But assuming that's not going to happen, here's what I think could make the schism easier to deal with. *** Convenience functions *** Here's a list of things I actually use frequently in phobos, ordered roughly by frequency of use: std.stdio : writef,writefln std.string : format std.math std.conv std.regexp std.path std.stream : BufferedFile std.file : exists,isFile,isDir If there were equivalently easy-to-use versions of those in Tango, that would cover my uses. And maybe there are already for some, but i see for example that std.path is replaced by a cumbersome OO interface, and

the OO of this particular item is very often much cheaper regarding the heap (which is why it is OO), and it has changed quite a bit recently. I just wish we had struct ctors in D v1 ...
 std.conv has no recommended equivalent.
 [http://www.dsource.org/projects/tango/wiki/PhobosTangoMigration]

Unfortunately, that page is woefully out of date :( I'll just touch briefly on some the packages you mentioned: - tango.math is all free-function, I think? - regexp is no different than phobos that I know of - I'd imagine std.conv is handled by the (free-function) modules in tango.text.convert ? - the equivalent of a 'format' function is probably covered by tango.text.convert.Format module
 Anyway, to use anything beyond those few up there (and even some of those) 
 I have to look up what the API is on the web page.

 BUT one advantage of Phobos there, is that I can find anything I need 
 pretty quickly with that list of modules on the left hand side of the 
 Phobos page.

agreed
 *** Better API documentation ***

 In contrast, the closest thing with Tango seems to be the Tango API Index 
 (http://www.dsource.org/projects/tango/docs/current/) which has a huge 
 list of names of everything in Tango, much of which is implementation 
 detail users shouldn't be mucking with.   So it's hard to find the thing 
 you're looking for if you just want to know how to open a file.

Very good point. There's something in the works to address that specific issue.
 I think a simplified module index that omits things users won't generally 
 need would help on that front.  And a one-line description next to each 
 link wouldn't hurt either.  Topical groupings might help too.  Like have a 
 list of every module related to "Text Processing" "Networking".  The 
 categories in the reference manual might be a good place to start.

Yes; topical groupings (perhaps by package) would be much better. In tango, each package tends to address a specific need, so that might work out.
 Another Tango doc gripe is that the modules don't have any useful 
 module-level descriptions.  Look at phobos' std.conv for comparison: 
 http://www.digitalmars.com/d/1.0/phobos/std_conv.html
 The page starts off with a useful description of what std.conv is for. 
 Given that, I can quickly tell if std.conv is the right module for the job 
 or not (as in it provides atoi and atol type conversions, rather than 
 being a module for doing temperature conversions or image convolutions or 
 something).  Other modules in Phobos are even better, like std.boxer, 
 giving both a quick overview *and* a few basic usage examples.

Another solid point
 *** Easier switching back and forth ***

 It seems that installing Tango itself is pretty easy now, at least if

Is this linux? I think Win32 has certainly been easy for a long time, but the linux packaging has never had a true 'installer' or whatever since nobody in the linux world can agree on what that should be :) Any suggestions there?
 you have dsss installed, but AFAIK that renders all your phobos-based libs 
 useless.  Tango should do two things to make switching back and forth 
 easier.
 1) Tanogobos should be a part of the default install

That may happen, if we can avoid the maintenance concerns
 2) A solution for tango-phobos switching should be installed by default. I 
 don't care how it's done but I think it should come in two flavors:
   a) a per-shell transient method for changing the default
   b) a global per-installation (or per-user if there's some way to get 
 that) method.

Aye
 As someone who still has a lot of code written that depends on Phobos, I 
 want to know that I can go back and forth between Phobos and Tango easily. 
 Right now if I want to install Tango and still use Phobos occasionally, I 
 have to choose between three different fiddly techniques 
 (http://www.dsource.org/projects/tango/wiki/PhobosTangoCooperation). The 
 web page gives no reason to prefer one method over another, so that means 
 I have to read all three and understand how they work well enough to 
 determine which method is the best for me.  Something like this should 
 just happen automatically as a part of installing Tango.

That would be great!
 If I'm going to write a library that depends on Tango, I want to be able 
 to say to potential users that all they have to do to use it is:

 """
    1) Install tango (dsss net install tango).
    2) Type the command "set_dlibrary tango"[*] at a command prompt.
 and later
    3) if you need to go back to Phobos type "set_dlibrary phobos"[*]

 [*] To make the switch persistent use "set_dlibrary -p"
 """

We need a volunteer to write this <g>
 Achieving this level of simplicity probably requires some cooperation from 
 Walter.  But it seems utterly attainable.  Unlike merging the runtimes.

All good and valid points, and taken note of. Thanks for making the effort
Oct 10 2007
prev sibling next sibling parent reply BCS <ao pathlink.com> writes:
I'd say a bunch here but most of it would just echo Bill. A few points though:

I have a project that uses only selective imports and has a filter in the 
build script to list the imported symbols. here is the list

File
FileMode
MemoryStream
ReadException
SeekPos
Stream
pow
toString
toUTF16
toUTF8
writef

Just for reference...

Another thing. as far as docs go. Tango could use some work. What I ant to 
see is, for each sub system, a overview of what it is, how it works (500 
ft overview of the whole sub-system) and how to use it. Ideally, this would 
all fit on one screen so two, maybe three paragraphs. As an example I'll 
use the IO stuff (the lack of this exact kind of docs for the IO subsystem 
is one of the *primary reasons* I don't use Tango [*HINT HINT HINT* flashing 
red 48pt font]): what I'd want would be a description of what the parts are, 
and how they fit together. Here is an example of the type of overview I would 
want:

 "a Foo is a source or sink for data like a file or network connection. A 
Baz is a pass though filter that does something to it like compression or 
encryption. A Bar is a near side end for interfacing with IO, it allows you 
to format data, wright raw data, read data, parse data, etc. If you want 
to do something like multiplex many data paths over one, you will need to 
implement the Baz interface."

That would be a good start. Then go into a bit more detail about what each 
part is expected to do.
Oct 10 2007
parent reply "Kris" <foo bar.com> writes:
"BCS" <ao pathlink.com> wrote in message 
news:ce0a33432476f8c9d9a29608a586 news.digitalmars.com...
 I'd say a bunch here but most of it would just echo Bill. A few points 
 though:

 I have a project that uses only selective imports and has a filter in the 
 build script to list the imported symbols. here is the list

 File
 FileMode
 MemoryStream
 ReadException
 SeekPos
 Stream
 pow
 toString
 toUTF16
 toUTF8
 writef

That's useful. Cheers!
 Just for reference...

 Another thing. as far as docs go. Tango could use some work. What I ant to 
 see is, for each sub system, a overview of what it is, how it works (500 
 ft overview of the whole sub-system) and how to use it. Ideally, this 
 would all fit on one screen so two, maybe three paragraphs. As an example 
 I'll use the IO stuff (the lack of this exact kind of docs for the IO 
 subsystem is one of the *primary reasons* I don't use Tango [*HINT HINT 
 HINT* flashing red 48pt font]):

Duly noted :)
 what I'd want would be a description of what the parts are, and how they 
 fit together. Here is an example of the type of overview I would want:

 "a Foo is a source or sink for data like a file or network connection. A 
 Baz is a pass though filter that does something to it like compression or 
 encryption. A Bar is a near side end for interfacing with IO, it allows 
 you to format data, wright raw data, read data, parse data, etc. If you 
 want to do something like multiplex many data paths over one, you will 
 need to implement the Baz interface."

 That would be a good start. Then go into a bit more detail about what each 
 part is expected to do.

That's great. Succinct and to the point. You want a job? :p Seriously though, you're absolutely right. Thanks
Oct 10 2007
parent reply BCS <ao pathlink.com> writes:
Reply to kris,

 "BCS" <ao pathlink.com> wrote in message

 [*HINT HINT HINT* flashing red 48pt font]):
 


I was hopeing I wouldn't need to get out the fog horn <G>
 


If you will check the history of Tango you will find my name under the heading of "came on to do docs and didn't do any". Mostly that was an artifact of me being over committed at the time. And it just so happens that a still am. :-b
Oct 10 2007
parent "Kris" <foo bar.com> writes:
"BCS" <ao pathlink.com> wrote in message

 If you will check the history of Tango you will find my name under the 
 heading of "came on to do docs and didn't do any". Mostly that was an 
 artifact of me being over committed at the time. And it just so happens 
 that a still am. :-b

lol ... any time you want to jump in, please, be our guest! The door is always open :)
Oct 10 2007
prev sibling parent Michael Hewitt <dlangassist gmail.com> writes:
Everyone,

I'm sure what I'm about to say is both naive and obvious, but hopefully it 
will be helpful nonetheless.  As an experienced C++ programmer and new D 
programmer who is considering using D as our primary development language, 
I come at this from a very simple perspective.  I don't really think in terms 
of Phobos and Tango.  I think in terms of the D runtime (aka Phobos) and 
other useful D libraries.  Tango seems like it might have some useful OO 
functionality, but since it is not compatible with the D runtime, I am unable 
to use it.

Bill and Benjamin's lists seem good to me, but even if Tango supported non-OO 
versions of these, I still am inclined toward my admittedly simplistic attitude 
of starting with "the D runtime".  Thus, until Tango either is "the D runtime" 
(i.e. Phobos is deprecated), or is compatible with "the D runtime", I am 
unlikely to use it.  One other comment is that the C-ish flavor of the D 
runtime (e.g. stdio) is quite palatable to new D programmers coming from 
C/C++, of whom there are bound to be many in the future if D is successful. 
 Another comment is that two competing, incompatible runtime libraries is 
a detriment to attracting new programmers to D.

I hope this is helpful.  I don't mean to start a war; I'm just providing 
insight from the perspective of a new D programmer coming from C/C++.

- Mike
Oct 11 2007
prev sibling parent reply Marcin Kuszczak <aarti_nospam please_interia.pl> writes:
Kris wrote:


 And that's where the misconception comes in. The benefits in the high
 level of Tango are often based upon the capabilities in the "lower"
 levels. Which is why the earlier question had been posed about Tango I/O.
 You don't get Tango without the I/O package, because that is one of the
 definitive differences between the two libraries. In short, there's
 nothing in Phobos that Tango would benefit from. When it comes to I/O, for
 example, Tango seriously outperforms every other library we've bothered to
 test. When it comes to string processing, the same is true. This is due to
 the design of Tango.
 

I don't want to drop Tango IO. :-) Probably I express myself not enough clear with my idea. It would be great if you could comment on my replay to Larsivi: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=59960 Thanks! -- Regards Marcin Kuszczak (Aarti_pl) ------------------------------------- Ask me why... I believe in Jesus - http://www.zapytajmnie.com (en/pl) Doost (port of few Boost libraries) - http://www.dsource.org/projects/doost/ -------------------------------------
Oct 10 2007
parent reply "Kris" <foo bar.com> writes:
"Marcin Kuszczak" <aarti_nospam please_interia.pl> wrote in message 
news:fejdk1$pvv$1 digitalmars.com...
 Kris wrote:


 And that's where the misconception comes in. The benefits in the high
 level of Tango are often based upon the capabilities in the "lower"
 levels. Which is why the earlier question had been posed about Tango I/O.
 You don't get Tango without the I/O package, because that is one of the
 definitive differences between the two libraries. In short, there's
 nothing in Phobos that Tango would benefit from. When it comes to I/O, 
 for
 example, Tango seriously outperforms every other library we've bothered 
 to
 test. When it comes to string processing, the same is true. This is due 
 to
 the design of Tango.

I don't want to drop Tango IO. :-) Probably I express myself not enough clear with my idea. It would be great if you could comment on my replay to Larsivi: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=59960 Thanks!

Sure; the quick and easy answer it this: Tango is also a better /low-level/ library than Phobos. Really, it is :) If you want to get a thin library up and running on a cell phone or whatever, Tango would totally be the right choice. Why? Because the team went to great effort to make the library (a) decoupled and (b) layered. Not only is the so-called Runtime isolated and is even packaged separately, but the middle and upper layers have limited interdependencies amongst them. It's not Utopia, since there are always tradeoffs to make. For example, the Tango logging package was previously distinct from the string formatting package, so you didn't pay the price of the dependency unless *you* wanted it. Well, recently, that changed because the benefit of coupling the two outweighed the isolation benefit. That's a fair example of a trade-off that was somewhat on the fence to begin with, and finally decided which side it wanted to be on :) Elsewhere we use a small set of interfaces to decouple the implementation of modules, such that (a) implementation can be plugged in and (b) the implementation modules themselves do not import each other; and are fully decoupled. Altogether, this makes Tango a very good choice as a mobile/modular library to target any kind of environment ... it was /designed/ as such from the beginning, and enjoyed a reasonably long gestation period to explore the various tradeoffs. What's missing from Tango, I understand, is something that's more familiar for those who prefer a free-function model? If so, then I think those folks will find incremental changes in Tango that are moving in that direction. In addition, I promised some folk at the D conference that model would be exposed somehow ... so it is, and will continue to happen :) This is what prompted the earlier question: "what pieces of phobos would folks really like to see in Tango?". Or rephrased, What is it /about/ parts of phobos that some people prefer? I'm getting a good indication that certainly some people prefer the free-function aspect? I'd really like to hear more about that, particularly some specifics :) I'm asking these questions because nobody has answered the questions posed in the origin of this thread. So instead, this is an exploration of a potentially different approach to a merge. What sayeth thou?
Oct 10 2007
parent reply Christopher Wright <dhasenan gmail.com> writes:
Kris wrote:
 "Marcin Kuszczak" <aarti_nospam please_interia.pl> wrote in message 
 news:fejdk1$pvv$1 digitalmars.com...
 Kris wrote:


 And that's where the misconception comes in. The benefits in the high
 level of Tango are often based upon the capabilities in the "lower"
 levels. Which is why the earlier question had been posed about Tango I/O.
 You don't get Tango without the I/O package, because that is one of the
 definitive differences between the two libraries. In short, there's
 nothing in Phobos that Tango would benefit from. When it comes to I/O, 
 for
 example, Tango seriously outperforms every other library we've bothered 
 to
 test. When it comes to string processing, the same is true. This is due 
 to
 the design of Tango.

Probably I express myself not enough clear with my idea. It would be great if you could comment on my replay to Larsivi: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=59960 Thanks!

Sure; the quick and easy answer it this: Tango is also a better /low-level/ library than Phobos. Really, it is :) If you want to get a thin library up and running on a cell phone or whatever, Tango would totally be the right choice. Why? Because the team went to great effort to make the library (a) decoupled and (b) layered. Not only is the so-called Runtime isolated and is even packaged separately, but the middle and upper layers have limited interdependencies amongst them. It's not Utopia, since there are always tradeoffs to make. For example, the Tango logging package was previously distinct from the string formatting package, so you didn't pay the price of the dependency unless *you* wanted it. Well, recently, that changed because the benefit of coupling the two outweighed the isolation benefit. That's a fair example of a trade-off that was somewhat on the fence to begin with, and finally decided which side it wanted to be on :) Elsewhere we use a small set of interfaces to decouple the implementation of modules, such that (a) implementation can be plugged in and (b) the implementation modules themselves do not import each other; and are fully decoupled. Altogether, this makes Tango a very good choice as a mobile/modular library to target any kind of environment ... it was /designed/ as such from the beginning, and enjoyed a reasonably long gestation period to explore the various tradeoffs. What's missing from Tango, I understand, is something that's more familiar for those who prefer a free-function model? If so, then I think those folks will find incremental changes in Tango that are moving in that direction. In addition, I promised some folk at the D conference that model would be exposed somehow ... so it is, and will continue to happen :) This is what prompted the earlier question: "what pieces of phobos would folks really like to see in Tango?". Or rephrased, What is it /about/ parts of phobos that some people prefer? I'm getting a good indication that certainly some people prefer the free-function aspect? I'd really like to hear more about that, particularly some specifics :) I'm asking these questions because nobody has answered the questions posed in the origin of this thread. So instead, this is an exploration of a potentially different approach to a merge. What sayeth thou?

I don't care about free functions versus objects, but I care about the amount of typing I have to do. And it seems that object names are about as long as function names, and method names are about as long as function names, so using an object-oriented interface involves twice as much typing. If you had "alias formatln fln" in Print, for instance, I could just write: Stdout.fln("whatever"); That's about a three character penalty above writefln, which I wouldn't notice. The current seven-character penalty is slightly annoying. I don't like instantiating objects in order to do a simple test: if (new FilePath(path).exists && !new FilePath(path).isFolder) { // do stuff } versus: if (Path.exists(path) && Path.isFolder(path)) { // do stuff } Personally, I like having these singletons as a matter of organization. I could use static imports instead, though.
Oct 11 2007
parent reply "Kris" <foo bar.com> writes:
"Christopher Wright" <dhasenan gmail.com> wrote in message 
news:fel8ir$1crd$1 digitalmars.com...
 I don't care about free functions versus objects, but I care about the 
 amount of typing I have to do. And it seems that object names are about as 
 long as function names, and method names are about as long as function 
 names, so using an object-oriented interface involves twice as much 
 typing.

 If you had "alias formatln fln" in Print, for instance, I could just 
 write:
 Stdout.fln("whatever");

 That's about a three character penalty above writefln, which I wouldn't 
 notice. The current seven-character penalty is slightly annoying.

Noted, and thank you
 I don't like instantiating objects in order to do a simple test:
 if (new FilePath(path).exists && !new FilePath(path).isFolder) {
    // do stuff
 }

 versus:
 if (Path.exists(path) && Path.isFolder(path)) {
    // do stuff
 }

This is definately a pain point I've heard often. The approach in Tango would be something like: auto path = FilePath ("some path"); if (path.exists && !path.isFolder) { // do stuff That's not so bad, is it? But yeah, I'd really like to hear more about this one in particular, because it seems to be a litmus test in some ways. Thanks! .
Oct 11 2007
next sibling parent BCS <ao pathlink.com> writes:
Reply to kris,

 "Christopher Wright" <dhasenan gmail.com> wrote in message
 news:fel8ir$1crd$1 digitalmars.com...
 
 I don't care about free functions versus objects, but I care about
 the amount of typing I have to do. And it seems that object names are
 about as long as function names, and method names are about as long
 as function names, so using an object-oriented interface involves
 twice as much typing.
 
 If you had "alias formatln fln" in Print, for instance, I could just
 write:
 Stdout.fln("whatever");
 That's about a three character penalty above writefln, which I
 wouldn't notice. The current seven-character penalty is slightly
 annoying.
 

 I don't like instantiating objects in order to do a simple test:
 if (new FilePath(path).exists && !new FilePath(path).isFolder) {
 // do stuff
 }
 versus:
 if (Path.exists(path) && Path.isFolder(path)) {
 // do stuff
 }

Tango would be something like: auto path = FilePath ("some path"); if (path.exists && !path.isFolder) { // do stuff That's not so bad, is it? But yeah, I'd really like to hear more about this one in particular, because it seems to be a litmus test in some ways. Thanks! .

with opImplicitCast you could get: if (new FilePath(path).exists(path).isFolder(path)) using somthing like this: class FilePath { struct Sub { FilePath fp; bool val = true; Sub Predicate(...) { auto ret = *this; ret.val &= test; return ret; } bool opImplictCast(){return val;} } Sub opImplictCast(){Sub ret; ret.fp = this; return ret;} }
Oct 11 2007
prev sibling parent reply Regan Heath <regan netmail.co.nz> writes:
Kris wrote:
 "Christopher Wright" <dhasenan gmail.com> wrote in message 
 news:fel8ir$1crd$1 digitalmars.com...
 I don't care about free functions versus objects, but I care about the 
 amount of typing I have to do. And it seems that object names are about as 
 long as function names, and method names are about as long as function 
 names, so using an object-oriented interface involves twice as much 
 typing.

 If you had "alias formatln fln" in Print, for instance, I could just 
 write:
 Stdout.fln("whatever");

 That's about a three character penalty above writefln, which I wouldn't 
 notice. The current seven-character penalty is slightly annoying.

Noted, and thank you
 I don't like instantiating objects in order to do a simple test:
 if (new FilePath(path).exists && !new FilePath(path).isFolder) {
    // do stuff
 }

 versus:
 if (Path.exists(path) && Path.isFolder(path)) {
    // do stuff
 }

This is definately a pain point I've heard often. The approach in Tango would be something like: auto path = FilePath ("some path"); if (path.exists && !path.isFolder) { // do stuff That's not so bad, is it?

Well.. if we make the assumption that isFolder will return false if is doesn't exist all you're really asking is: if (isFolder("some path")) { and if that is the extent of it then the free function is more appropriate, it's quicker, easier, involves no heap allocation, etc. In a more complicated situation I would argue for the class but that's the point I'm trying to make, in some situations one is more appropriate than the other. Regan p.s. to my mind the amount of typing involved isn't really important as copy+paste has been my friend for a long time and auto-completion almost as long.
Oct 11 2007
next sibling parent reply BCS <ao pathlink.com> writes:
Reply to Regan,


 
 p.s. to my mind the amount of typing involved isn't really important
 as copy+paste has been my friend for a long time and auto-completion
 almost as long.
 

as a bit of an aside: the amount of text it take to do something effect how much of a function I can put on my screen at any given time.
Oct 11 2007
parent reply Christopher Wright <dhasenan gmail.com> writes:
BCS wrote:
 as a bit of an aside: the amount of text it take to do something effect 
 how much of a function I can put on my screen at any given time.

No, no! Even with a verbose standard library, your functions should always fit on one screen of text, except in a few extreme cases. Or so the gods of test-driven development tell me. I just don't want carpal tunnel before my time, so that means either praying for a more succinct naming convention in the stdlib, or getting Jetbrains to support D.
Oct 11 2007
parent BCS <ao pathlink.com> writes:
Reply to Christopher,

 BCS wrote:
 
 as a bit of an aside: the amount of text it take to do something
 effect how much of a function I can put on my screen at any given
 time.
 

Even with a verbose standard library, your functions should always fit on one screen of text, except in a few extreme cases. Or so the gods of test-driven development tell me.

I'll grant you that, but sometime it just isn't worth it. (I have a function that is just a page and a half of switch statement with one or two ops per case. Yes that may be an indication of bad design but the alternatives that come to mind are worse) If you lay out your code correctly and the function are short enough you can often get several related function on the screen at once. Also if the function is shorter (and does the same stuff) than I can put more comments at the top and still be able to see it all. A third thing is that I can read it faster with shorter names (less pan time for my eye-balls and less noise to filter). If you want to be really nit picky, it also should compile a bit faster.
 
 I just don't want carpal tunnel before my time, so that means either
 praying for a more succinct naming convention in the stdlib, or
 getting Jetbrains to support D.
 

Oct 11 2007
prev sibling next sibling parent reply Chad J <gamerChad _spamIsBad_gmail.com> writes:
Regan Heath wrote:
 
 p.s. to my mind the amount of typing involved isn't really important as 
 copy+paste has been my friend for a long time and auto-completion almost 
 as long.

It'd be the same for me if I could have like 8 things copied at once, but I can't. I might be able to fix that, but it seems like I shouldn't have to. So in essence I have more important things to spend my copy+paste on than Stdout.etcetcetc(). Code completion doesn't exist for me. I still don't know where to find that lightweight, highly configurable, slick, IDE for D that runs on both Windows and Linux. Until then, it's all about the ATEs. Descent is tempting, but I don't like having to wait for my editor to open.
Oct 11 2007
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Chad J wrote:
 Descent 
 is tempting, but I don't like having to wait for my editor to open.

Easily fixed. Just don't close it :P.
Oct 11 2007
next sibling parent "Kris" <foo bar.com> writes:
Was gonna say the same thing :)


"Frits van Bommel" <fvbommel REMwOVExCAPSs.nl> wrote in message 
news:femfo2$uig$1 digitalmars.com...
 Chad J wrote:
 Descent is tempting, but I don't like having to wait for my editor to 
 open.

Easily fixed. Just don't close it :P.

Oct 11 2007
prev sibling parent reply Don Clugston <dac nospam.com.au> writes:
Frits van Bommel wrote:
 Chad J wrote:
 Descent is tempting, but I don't like having to wait for my editor to 
 open.

Easily fixed. Just don't close it :P.

Any idea what's wrong with Eclipse? Why is the startup so unbelievably slow? Seems to be about 25,000 million clock cycles! (Is this typical of Java apps? It's the almost the only Java app I've ever used). What on earth is it doing? (Genuine question, not a flame).
Oct 12 2007
parent reply "Kris" <foo bar.com> writes:
"Don Clugston" <dac nospam.com.au> wrote in message news:fen7rf$17r7>

 Any idea what's wrong with Eclipse? Why is the startup so unbelievably 
 slow?
 Seems to be about 25,000 million clock cycles!
 (Is this typical of Java apps? It's the almost the only Java app I've ever 
 used).
 What on earth is it doing? (Genuine question, not a flame).

inspecting your licenses, Don :)
Oct 12 2007
parent Sean Kelly <sean f4.ca> writes:
Kris wrote:
 "Don Clugston" <dac nospam.com.au> wrote in message news:fen7rf$17r7>
 
 Any idea what's wrong with Eclipse? Why is the startup so unbelievably 
 slow?
 Seems to be about 25,000 million clock cycles!
 (Is this typical of Java apps? It's the almost the only Java app I've ever 
 used).
 What on earth is it doing? (Genuine question, not a flame).

inspecting your licenses, Don :)

Licenses!? We ain't got no licenses. We don't need no licenses! I don't have to show Eclipse any stinking licenses!! Sean
Oct 12 2007
prev sibling parent "Kris" <foo bar.com> writes:
"Regan Heath" <regan netmail.co.nz> wrote in message 
news:felol1$2fte$1 digitalmars.com...
 Kris wrote:
 "Christopher Wright" <dhasenan gmail.com> wrote in message 
 news:fel8ir$1crd$1 digitalmars.com...
 I don't care about free functions versus objects, but I care about the 
 amount of typing I have to do. And it seems that object names are about 
 as long as function names, and method names are about as long as 
 function names, so using an object-oriented interface involves twice as 
 much typing.

 If you had "alias formatln fln" in Print, for instance, I could just 
 write:
 Stdout.fln("whatever");

 That's about a three character penalty above writefln, which I wouldn't 
 notice. The current seven-character penalty is slightly annoying.

Noted, and thank you
 I don't like instantiating objects in order to do a simple test:
 if (new FilePath(path).exists && !new FilePath(path).isFolder) {
    // do stuff
 }

 versus:
 if (Path.exists(path) && Path.isFolder(path)) {
    // do stuff
 }

This is definately a pain point I've heard often. The approach in Tango would be something like: auto path = FilePath ("some path"); if (path.exists && !path.isFolder) { // do stuff That's not so bad, is it?

Well.. if we make the assumption that isFolder will return false if is doesn't exist all you're really asking is: if (isFolder("some path")) { and if that is the extent of it then the free function is more appropriate, it's quicker, easier, involves no heap allocation, etc. In a more complicated situation I would argue for the class but that's the point I'm trying to make, in some situations one is more appropriate than the other. Regan p.s. to my mind the amount of typing involved isn't really important as copy+paste has been my friend for a long time and auto-completion almost as long.

Point taken ... I was actually doing copy/paste myself, using the OP's example :)
Oct 11 2007
prev sibling parent "Anders Bergh" <anders1 gmail.com> writes:
On 10/11/07, Lars Ivar Igesund <larsivar igesund.net> wrote:
 How on earth is

 Cout("somestring"); more "complex" than writef (write actually)?

Upper-case "C"... Anders
Oct 11 2007