View mode: basic / threaded / horizontal-split · Log in · Help
December 23, 2012
Re: dlang.org Library Reference
On 2012-12-22 18:53, Sönke Ludwig wrote:

> In the latest upload a number of items is addressed:
>   - vertical margins at the top
>   - redundant column headers
>   - +/- signs for the package tree
>   - jumps to line numbers on github (which are off because of changes after the release)
>   - some macro processing fixes (e.g. std.array.popBack contained some bad HTML because of this)
>   - also moved the authors/license sections to the bottom to see how it looks

I'm looking at this page:

http://vibed.org/temp/d-programming-language.org/phobos/std/net/isemail/EmailStatusCode.html

I think it would be better if there was more space for the Name column 
and let the Description column automatically wrap. It's better that the 
description uses multiple rows than the symbol names.

-- 
/Jacob Carlborg
December 23, 2012
Re: dlang.org Library Reference
On 2012-12-22 17:15, Andrei Alexandrescu wrote:

> Looks great! I think that belongs in an index page (which doesn't exist
> yet, though we do define a sitemap http://dlang.org/sitemap.html).

The sitemap is a bit different. The list of symbols could be the index 
page or a part of the index page for the reference documentation, that 
is, this page:

http://dlang.org/phobos/index.html

-- 
/Jacob Carlborg
December 23, 2012
Re: dlang.org Library Reference
On Sunday, 23 December 2012 at 13:21:16 UTC, Andrei Alexandrescu 
wrote:
> On 12/23/12 6:44 AM, foobar wrote:
>> Using an all encompassing "algorithms" module is also 
>> unhelpful as all
>> code is essentially an algorithm to accomplish some task. This 
>> is akin
>> to opening a store called - "A store" or perhaps "A place to 
>> sell you
>> stuff".
>
> That I disagree with a bit. I think it's rather clear that 
> std.algorithm includes classic, consecrated algorithms the kind 
> you'll find in a book entitled "Algorithms". By your argument a 
> book called "Algorithms" would not make sense because it would 
> need to describe the entire computing world.
>
> So if I'm looking for sort, I'd open "algorithm". If I'm 
> looking for parsing program options, I wouldn't expect it to be 
> in the same place.
>
>> As a client of said shop, I want a better description if I to 
>> buy at the
>> shop. Even a general "Clothes shop" is already much better. 
>> For 3rd
>> party it also often makes sense to have a brand name - e.g we 
>> all know
>> what "vibe.d" is all about.
>
> Such differentiation is also useful.
>
>
> Andrei

Does it mean you agree with the rest? :)

Regarding std.algorithm, the module isn't called - 'classic, 
consecrated algorithms the kind you'll find in a book entitled 
"Algorithms"'. It is simply called 'std.algorithm' and there are 
many, *many* books on algorithms. Should this module include 
concurrent algorithms? Should it include distributed algorithms? 
Should it include statistic algorithms? Should it include natural 
language processing algorithms? Should it include genetic 
algorithms? I think it's clear by now that the name does not 
convey what you intend it to convey.

A much better and more user friendly scheme would be to classify 
the algorithms by their *functionality* and not by some undefined 
"belongs to classical algorithms books" relation.
e.g. "Sorting algorithms", "Set operations", etc.
Now, if I want to sort something I know to "shop" at the "sorting 
algorithms" outlet and don't need to spend time going over a 
potentially infinite list of algorithms.
December 23, 2012
Re: dlang.org Library Reference
On 12/23/12 9:08 AM, foobar wrote:
> Regarding std.algorithm, the module isn't called - 'classic, consecrated
> algorithms the kind you'll find in a book entitled "Algorithms"'. It is
> simply called 'std.algorithm' and there are many, *many* books on
> algorithms. Should this module include concurrent algorithms? Should it
> include distributed algorithms? Should it include statistic algorithms?
> Should it include natural language processing algorithms? Should it
> include genetic algorithms? I think it's clear by now that the name does
> not convey what you intend it to convey.

Importing std.container doesn't mean all containers conceivable will be 
there, and so on. Sense and sensibility must always be exercised.

> A much better and more user friendly scheme would be to classify the
> algorithms by their *functionality* and not by some undefined "belongs
> to classical algorithms books" relation.
> e.g. "Sorting algorithms", "Set operations", etc.
> Now, if I want to sort something I know to "shop" at the "sorting
> algorithms" outlet and don't need to spend time going over a potentially
> infinite list of algorithms.

I like std.algorithm the way it is.


Andrei
December 23, 2012
Re: dlang.org Library Reference
On Sunday, 23 December 2012 at 14:43:25 UTC, Andrei Alexandrescu 
wrote:
> On 12/23/12 9:08 AM, foobar wrote:
>> Regarding std.algorithm, the module isn't called - 'classic, 
>> consecrated
>> algorithms the kind you'll find in a book entitled 
>> "Algorithms"'. It is
>> simply called 'std.algorithm' and there are many, *many* books 
>> on
>> algorithms. Should this module include concurrent algorithms? 
>> Should it
>> include distributed algorithms? Should it include statistic 
>> algorithms?
>> Should it include natural language processing algorithms? 
>> Should it
>> include genetic algorithms? I think it's clear by now that the 
>> name does
>> not convey what you intend it to convey.
>
> Importing std.container doesn't mean all containers conceivable 
> will be there, and so on. Sense and sensibility must always be 
> exercised.
>
>> A much better and more user friendly scheme would be to 
>> classify the
>> algorithms by their *functionality* and not by some undefined 
>> "belongs
>> to classical algorithms books" relation.
>> e.g. "Sorting algorithms", "Set operations", etc.
>> Now, if I want to sort something I know to "shop" at the 
>> "sorting
>> algorithms" outlet and don't need to spend time going over a 
>> potentially
>> infinite list of algorithms.
>
> I like std.algorithm the way it is.
>
>
> Andrei

On Sunday, 23 December 2012 at 14:43:25 UTC, Andrei Alexandrescu
wrote:
> On 12/23/12 9:08 AM, foobar wrote:
>> Regarding std.algorithm, the module isn't called - 'classic, 
>> consecrated
>> algorithms the kind you'll find in a book entitled 
>> "Algorithms"'. It is
>> simply called 'std.algorithm' and there are many, *many* books 
>> on
>> algorithms. Should this module include concurrent algorithms? 
>> Should it
>> include distributed algorithms? Should it include statistic 
>> algorithms?
>> Should it include natural language processing algorithms? 
>> Should it
>> include genetic algorithms? I think it's clear by now that the 
>> name does
>> not convey what you intend it to convey.
>
> Importing std.container doesn't mean all containers conceivable 
> will be there, and so on. Sense and sensibility must always be 
> exercised.
>
>> A much better and more user friendly scheme would be to 
>> classify the
>> algorithms by their *functionality* and not by some undefined 
>> "belongs
>> to classical algorithms books" relation.
>> e.g. "Sorting algorithms", "Set operations", etc.
>> Now, if I want to sort something I know to "shop" at the 
>> "sorting
>> algorithms" outlet and don't need to spend time going over a 
>> potentially
>> infinite list of algorithms.
>
> I like std.algorithm the way it is.
>
>
> Andrei

Same here. In my mind it's about generality:

General purpose algorithms (sort, partition etc.) belong in
std.algorithm and more specific algorithms belong in their own
appropriately named modules.
December 23, 2012
std.algorithm (Was: dlang.org Library Reference)
On Sunday, 23 December 2012 at 16:06:57 UTC, John Colvin wrote:
> On Sunday, 23 December 2012 at 14:43:25 UTC, Andrei 
> Alexandrescu wrote:
>> I like std.algorithm the way it is.
>>
>>
>> Andrei
>
> Same here. In my mind it's about generality:
>
> General purpose algorithms (sort, partition etc.) belong in
> std.algorithm and more specific algorithms belong in their own
> appropriately named modules.

Levenshtein distance is general purpose?

I'm not too fussed about std.algorithm, but I think it could be 
better. Here's some criticisms I have:

1. The iteration algorithms should be std.range. I find it 
confusing that (for example) joiner and chain are in different 
modules when they are so similar.

2. The set algorithms should be in their own module. They are 
rarely used and quite specific in what they do.

3. The sorting algorithms should be in their own module. There 
are many different sorting algorithms that could be added, and if 
they stay in std.algorithm then it is going to get quite bloated.

Interestingly, EASTL also decided to split C++'s <algorithm> into 
sorting, set, and heap components. I think this is the right 
thing to do.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html

My main worry is that std.algorithm becomes std.miscellaneous -- 
a place where things go when you can't think where else to put 
them. The reason this happens is because of the name. As someone 
mentioned earlier, just about every function implements an 
"algorithm" of some sort, so people can feel justified in putting 
everything in std.algorithm. Heck, if "min" is an "algorithm" 
then anything is!

Would it be possible to split the library up and add public 
imports to std.algorithm of the moved symbols?
December 23, 2012
Re: std.algorithm (Was: dlang.org Library Reference)
On 12/23/12 12:54 PM, Peter Alexander wrote:
> On Sunday, 23 December 2012 at 16:06:57 UTC, John Colvin wrote:
>> On Sunday, 23 December 2012 at 14:43:25 UTC, Andrei Alexandrescu wrote:
>>> I like std.algorithm the way it is.
>>>
>>>
>>> Andrei
>>
>> Same here. In my mind it's about generality:
>>
>> General purpose algorithms (sort, partition etc.) belong in
>> std.algorithm and more specific algorithms belong in their own
>> appropriately named modules.
>
> Levenshtein distance is general purpose?

There's always stuff on the fringes that could be debated one way or 
another.

> I'm not too fussed about std.algorithm, but I think it could be better.
> Here's some criticisms I have:
>
> 1. The iteration algorithms should be std.range. I find it confusing
> that (for example) joiner and chain are in different modules when they
> are so similar.

I agree, but then I guess it's not too bad the way it is.

> 2. The set algorithms should be in their own module. They are rarely
> used and quite specific in what they do.

But then there's stuff such as group that is set-oriented yet quite 
useful in general.

> 3. The sorting algorithms should be in their own module. There are many
> different sorting algorithms that could be added, and if they stay in
> std.algorithm then it is going to get quite bloated.

I guess. But then approaches could be implemented as policies to sort etc.

> Interestingly, EASTL also decided to split C++'s <algorithm> into
> sorting, set, and heap components. I think this is the right thing to do.
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html
>
> My main worry is that std.algorithm becomes std.miscellaneous -- a place
> where things go when you can't think where else to put them. The reason
> this happens is because of the name. As someone mentioned earlier, just
> about every function implements an "algorithm" of some sort, so people
> can feel justified in putting everything in std.algorithm. Heck, if
> "min" is an "algorithm" then anything is!
>
> Would it be possible to split the library up and add public imports to
> std.algorithm of the moved symbols?

To be frank, I look at the problems D is facing right now and really the 
(re)organization of std.algorithm is nowhere near the top of the list. 
If we were a perfectly efficient forum, we wouldn't be discussing it now 
at all.


Andrei
December 23, 2012
Re: dlang.org Library Reference
Am 23.12.2012 14:52, schrieb Jacob Carlborg:
> On 2012-12-22 18:53, Sönke Ludwig wrote:
> 
>>   - jumps to line numbers on github (which are off because of changes after the release)
> 
> Can you lock it to the same hash that the docs are generated from?
> 

I've locked it to the v2.060 tag now, but as far as I can see github also allows to brows arbitrary
hashes, so this shouldn't be a problem.
December 23, 2012
Re: dlang.org Library Reference
Am 23.12.2012 14:58, schrieb Jacob Carlborg:
> I think it would be better if there was more space for the Name column and let the Description
> column automatically wrap. It's better that the description uses multiple rows than the symbol names.
> 

I changed the first column from "width: 150pt;" to "min-width: 170pt". It can still wrap, but the
two columns can now freely fight for the space if they need to.
December 23, 2012
Re: std.algorithm (Was: dlang.org Library Reference)
On Sunday, December 23, 2012 18:54:15 Peter Alexander wrote:
> Would it be possible to split the library up and add public
> imports to std.algorithm of the moved symbols?

DIPs 15 and 16 relate to the ability to split up a module into separate 
modules within a package with the same name without breaking code. If 
something along those lines were implemented, it would potentially make some 
sense to reorganize std.algorithm as a package. I'd definitely break up 
std.datetime if something like that were implemented, but someone has to do 
it. I started looking into it at one point, but I have far higher priorities 
right now, so I didn't get very far and don't have time to tackle it right 
now.

- Jonathan M Davis
4 5 6 7 8 9
Top | Discussion index | About this forum | D home