On 9/5/2011 11:39 PM, Jacob Carlborg wrote:
> We don't want to have a standard library like the one in PHP where there seems
> to be no naming conventions at all.

I don't think that is the reason PHP is such a bear to work with.

Josh Simmons:

> My question is why do you even need a standard API for XML and JSON.

It helps port your user code to other libs that use the same standard API. This is very useful. In D I'd like a basic standard API even for simple 2D graphics.

Bye,
bearophile

On Tue, Sep 6, 2011 at 6:37 PM, bearophile <bearophileHUGS@lycos.com> wrote:
> Josh Simmons:
>
>> My question is why do you even need a standard API for XML and JSON.
>
> It helps port your user code to other libs that use the same standard API. This is very useful. In D I'd like a basic standard API even for simple 2D graphics.
>
> Bye,
> bearophile
>

This would be true if there were only implementation differences between libraries doing roughly the same thing (in which case you'd not need a new library anyway). Unfortunately this is not how things work.

So simple 2d graphics ey? vector or raster based? immediate rendering or scene graph representation? animation? fonts? textures?

XML ey? SAX, DOM, Pull, Data Binding? XPath? XSLT?

The problem with php isn't just it's awesome naming, it's the fact that anything that seemed like something somebody might use was added as opposed to limiting itself to the must-haves.

On 2011-09-06 08:56, Jonathan M Davis wrote:
> On Tuesday, September 06, 2011 08:42:14 Jacob Carlborg wrote:
>> On 2011-09-06 08:00, Walter Bright wrote:
>>> On 9/5/2011 7:48 PM, Andrei Alexandrescu wrote:
>>>> I agree with all of the above. However, as is often the case, there's
>>>> more than
>>>> one side to the story.
>>>>
>>>> Bad APIs have their costs too. We can't afford to have an XML library
>>>> that
>>>> offers few and badly packaged features and comes at the tail of all
>>>> benchmarks.
>>>> We also can't afford a JSON library that is poorly designed and badly
>>>> written.
>>>> Ironically, the costs mostly manifest the same way: people will decide
>>>> not to
>>>> use D because it "lacks good libraries" and "is quirky to use". In
>>>> many ways a
>>>> language's standard library is a showcase of the language, and to a
>>>> newcomer an
>>>> inconsistent and awkward standard library affects the perception of
>>>> the
>>>> language's quality.
>>>
>>> I agree that the XML and JSON libraries need to be scrapped and
>>> rewritten. But simply changing the names of otherwise successful APIs is
>>> not worth while.
>>
>> So we have to live with these naming conventions from C forever?
>
> My take on it is that we need to figure out which pieces of Phobos need to be
> reworked or renamed and get it done as soon as possible. That way, everything
> follows the proper naming conventions (thus avoiding a mess like PHP) and is
> of an appropriately high level of quality. Then we can have an appropriately
> stable API which doesn't have to change often - if at all. I think that the
> current problem with Phobos is primarily a combination of three things:
>
> 1. Older APIs which aren't in line with how D2 and Phobos have evolved (e.g.
> they don't use ranges when they should).
>
> 2. Some older stuff didn't get a thorough enough peer review before making it
> into Phobos and is not at a high enough level of quality, so it needs to be
> revised or replaced.
>
> 3. Too much of what has been done in the past has been a hodgepodge of naming
> conventions, making it very inconsistent in some places.
>
> Once those have been sorted out (some of which can be done without breaking
> any existing code and some of which requires breaking changes), then we can
> have a stable API for Phobos which doesn't change much except where we're
> adding new functionality which doesn't break existing code. So ultimately, we
> _will_ have a stable API, but some breaking changes are required in the short
> term to resolve issues with Phobos which would cause problems in the long run.
>
> - Jonathan M Davis

Yes, thank you, I agree.

-- 
/Jacob Carlborg

On 2011-09-06 09:35, Walter Bright wrote:
> On 9/5/2011 11:39 PM, Jacob Carlborg wrote:
>> We don't want to have a standard library like the one in PHP where
>> there seems
>> to be no naming conventions at all.
>
> I don't think that is the reason PHP is such a bear to work with.

I think that that is one reason, not the only one, not the biggest one, but one reason.

-- 
/Jacob Carlborg

On Tuesday, September 06, 2011 18:54:45 Josh Simmons wrote:
> On Tue, Sep 6, 2011 at 6:37 PM, bearophile <bearophileHUGS@lycos.com> wrote:
> > Josh Simmons:
> >> My question is why do you even need a standard API for XML and JSON.
> > 
> > It helps port your user code to other libs that use the same standard API. This is very useful. In D I'd like a basic standard API even for simple 2D graphics.
> > 
> > Bye,
> > bearophile
> 
> This would be true if there were only implementation differences between libraries doing roughly the same thing (in which case you'd not need a new library anyway). Unfortunately this is not how things work.
> 
> So simple 2d graphics ey? vector or raster based? immediate rendering or scene graph representation? animation? fonts? textures?
> 
> XML ey? SAX, DOM, Pull, Data Binding? XPath? XSLT?
> 
> The problem with php isn't just it's awesome naming, it's the fact that anything that seemed like something somebody might use was added as opposed to limiting itself to the must-haves.

Other major languages (such as Java and C#) have large standard libraries and have done quite well with them. In fact, I believe that the large size of their standard libraries is generally seen as major advantage of those languages.

No, we can't have everything in the standard library. No, an XML parser in the standard library likely won't meet everyone's needs. However, having a large standard library can be of great benefit to the users of the language even if it doesn't solve every problem that they could possibly have. The question isn't really whether we should add stuff like XML parsing to Phobos. The question is what is the best general implementation for a such a module and whether we can get an implementation of high enough quality to be able to go in the standard library. It's a question of time, man power, and quality.

Obviously, Phobos is not going to explode in size overnight, but it _is_ going to grow in size, and eventually it should be fairly large. We already have several useful additions in the review queue which will likely make it into Phobos in one form or another over the next few months.

- Jonathan M Davis

On 2011-09-06 11:09, Jonathan M Davis wrote:
> On Tuesday, September 06, 2011 18:54:45 Josh Simmons wrote:
>>
>> This would be true if there were only implementation differences
>> between libraries doing roughly the same thing (in which case you'd
>> not need a new library anyway). Unfortunately this is not how things
>> work.
>>
>> So simple 2d graphics ey? vector or raster based? immediate rendering
>> or scene graph representation? animation? fonts? textures?
>>
>> XML ey? SAX, DOM, Pull, Data Binding? XPath? XSLT?
>>
>> The problem with php isn't just it's awesome naming, it's the fact
>> that anything that seemed like something somebody might use was added
>> as opposed to limiting itself to the must-haves.
>
> Other major languages (such as Java and C#) have large standard libraries and
> have done quite well with them. In fact, I believe that the large size of
> their standard libraries is generally seen as major advantage of those
> languages.
>
> No, we can't have everything in the standard library. No, an XML parser in the
> standard library likely won't meet everyone's needs. However, having a large
> standard library can be of great benefit to the users of the language even if
> it doesn't solve every problem that they could possibly have. The question
> isn't really whether we should add stuff like XML parsing to Phobos. The
> question is what is the best general implementation for a such a module and
> whether we can get an implementation of high enough quality to be able to go
> in the standard library. It's a question of time, man power, and quality.

Phobos could have a low level XML parsing module and on top of that other XML APIs can be built, like SAX, DOM and so on. This is how the XML modules in Tango are built. Tango has a low level XML pull parse. Built on top of that are a SAX API and a DOM document.

> Obviously, Phobos is not going to explode in size overnight, but it _is_ going
> to grow in size, and eventually it should be fairly large. We already have
> several useful additions in the review queue which will likely make it into
> Phobos in one form or another over the next few months.
>
> - Jonathan M Davis


-- 
/Jacob Carlborg

On Tue, Sep 6, 2011 at 7:09 PM, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
> Other major languages (such as Java and C#) have large standard libraries and have done quite well with them. In fact, I believe that the large size of their standard libraries is generally seen as major advantage of those languages.
>
> No, we can't have everything in the standard library. No, an XML parser in the standard library likely won't meet everyone's needs. However, having a large standard library can be of great benefit to the users of the language even if it doesn't solve every problem that they could possibly have. The question isn't really whether we should add stuff like XML parsing to Phobos. The question is what is the best general implementation for a such a module and whether we can get an implementation of high enough quality to be able to go in the standard library. It's a question of time, man power, and quality.
>
> Obviously, Phobos is not going to explode in size overnight, but it _is_ going to grow in size, and eventually it should be fairly large. We already have several useful additions in the review queue which will likely make it into Phobos in one form or another over the next few months.
>
> - Jonathan M Davis
>

Other languages like C# and Java have large enterprise outfits backing their massive standard libraries too.

I just think the effort is better spent creating a solid language and encouraging third party libraries through better tools.

On Tuesday, September 06, 2011 19:29:13 Josh Simmons wrote:
> On Tue, Sep 6, 2011 at 7:09 PM, Jonathan M Davis <jmdavisProg@gmx.com>
wrote:
> > Other major languages (such as Java and C#) have large standard libraries and have done quite well with them. In fact, I believe that the large size of their standard libraries is generally seen as major advantage of those languages.
> > 
> > No, we can't have everything in the standard library. No, an XML parser in the standard library likely won't meet everyone's needs. However, having a large standard library can be of great benefit to the users of the language even if it doesn't solve every problem that they could possibly have. The question isn't really whether we should add stuff like XML parsing to Phobos. The question is what is the best general implementation for a such a module and whether we can get an implementation of high enough quality to be able to go in the standard library. It's a question of time, man power, and quality.
> > 
> > Obviously, Phobos is not going to explode in size overnight, but it _is_ going to grow in size, and eventually it should be fairly large. We already have several useful additions in the review queue which will likely make it into Phobos in one form or another over the next few months.
> > 
> > - Jonathan M Davis
> 
> Other languages like C# and Java have large enterprise outfits backing their massive standard libraries too.
> 
> I just think the effort is better spent creating a solid language and encouraging third party libraries through better tools.

For the most part, the folks working on Phobos are not the same folks who work on dmd. There's some overlap, but they're definitely not the same people. So, the fact that people are working on the standard library does _nothing_ to slow the language down. If anything, it helps, because it provides a standard code base which uses (and therefore tests) the various features of the language. Third party libraries are great, but I don't see why you would ever want to discourage development of a language's standard library in favor of third party libraries. In some cases, modules in the standard library have originated in third party libraries anyway.

No, Phobos is not likely to ever rival C# or Java for volume of code. But that doesn't mean that Phobos shouldn't try and be as large is it can be while still maintaining high quality.

- Jonathan M Davis

Josh Simmons:

> So simple 2d graphics ey? vector or raster based? immediate rendering or scene graph representation? animation? fonts? textures?

Raster, immediate rendering, no need to specify animations, basic support for fonts and textures. Leaving most things out is not a problem here. Time ago someone has shown here a nice D module that works on Windows, Linux, that's is short.  This module doesn't replace other graphics libs or GUI modules, it's something simple and small for small purposes.


> XML ey? SAX, DOM, Pull, Data Binding? XPath? XSLT?
> 
> The problem with php isn't just it's awesome naming, it's the fact that anything that seemed like something somebody might use was added as opposed to limiting itself to the must-haves.

Some people like wide libraries like Python (batteries included), others don't like that. Both choices have their serious advantages and serious disadvantages. There are not general rules to solve this problem, each case needs to be discussed. I think a good JSON module needs to be in Phobos, while for XML maybe it just needs a standard D API (this also comes from practical size considerations: a JSON module is probably small. A good XML module will probably become large).

Bye,
bearophile