View mode: basic / threaded / horizontal-split · Log in · Help
November 29, 2009
Phobos packages a bit confusing
Hi

after using D1 and Tango for couple of years we decided to experiment 
with D2 and Phobos in a small scale project. For some reason the mostly 
flat package hierarchy seemed rather confusing.

For instance, it took two of us 15 minutes to build a program that reads 
a line from user, converts the string to a natural number, adds one, and 
finally prints it to the screen. Entities like 'stdin' seem to have no 
documentation at all. What should I import to get it, what interfaces 
does it implement etc.

When writing this, I already forgot what package contained the to! 
template. My intuition says it should be in
* std.stdint [int related operations]
* std.format [number formats?]
* std.typecons [we're constructing a int from a string]
* std.string [the input was a string, maybe toInt is a string operation]
* std.numeric [it's a numeric operation, isn't it]

I admit using higher level languages has made major damage to my brain 
("500.1".toInt anyone?), but still using Tango, Java, or C# seems rather 
intuitive, but in Phobos the set of packages and their contents feels 
more or less arbitrary. Is there anything that can be done?
November 29, 2009
Re: Phobos packages a bit confusing
retard Wrote:

> Hi
> 
> after using D1 and Tango for couple of years we decided to experiment 
> with D2 and Phobos in a small scale project. For some reason the mostly 
> flat package hierarchy seemed rather confusing.
> 
> For instance, it took two of us 15 minutes to build a program that reads 
> a line from user, converts the string to a natural number, adds one, and 
> finally prints it to the screen. Entities like 'stdin' seem to have no 
> documentation at all. What should I import to get it, what interfaces 
> does it implement etc.

That's an interesting example considering how Tango IO is way more complex. Comparatively speaking, 15 minutes is great!

That being said, there probably are ways to make D2 Phobos easier to use.



> When writing this, I already forgot what package contained the to! 
> template. 

std.conv (for conversions)


> My intuition says it should be in
>  * std.stdint [int related operations]
>  * std.format [number formats?]
>  * std.typecons [we're constructing a int from a string]
>  * std.string [the input was a string, maybe toInt is a string operation]
>  * std.numeric [it's a numeric operation, isn't it]
> 
> I admit using higher level languages has made major damage to my brain 
> ("500.1".toInt anyone?), but still using Tango, Java, or C# seems rather 
> intuitive, but in Phobos the set of packages and their contents feels 
> more or less arbitrary. Is there anything that can be done?

Any massively used language is easier to use because a google search turns up similar code. I've found both D2 Phobos and Tango to be easy to use once you start. Tango was easier to find where most things were, but was amazingly tough to assemble generic pieces for IO. I remember reading line buffered text from standard in was way simpler with D2 Phobos.
November 29, 2009
Re: Phobos packages a bit confusing
retard wrote:
> Hi
> 
> after using D1 and Tango for couple of years we decided to experiment 
> with D2 and Phobos in a small scale project. For some reason the mostly 
> flat package hierarchy seemed rather confusing.
> 
> For instance, it took two of us 15 minutes to build a program that reads 
> a line from user, converts the string to a natural number, adds one, and 
> finally prints it to the screen. Entities like 'stdin' seem to have no 
> documentation at all. What should I import to get it, what interfaces 
> does it implement etc.
> 
> When writing this, I already forgot what package contained the to! 
> template. My intuition says it should be in
>  * std.stdint [int related operations]
>  * std.format [number formats?]
>  * std.typecons [we're constructing a int from a string]
>  * std.string [the input was a string, maybe toInt is a string operation]
>  * std.numeric [it's a numeric operation, isn't it]
> 
> I admit using higher level languages has made major damage to my brain 
> ("500.1".toInt anyone?), but still using Tango, Java, or C# seems rather 
> intuitive, but in Phobos the set of packages and their contents feels 
> more or less arbitrary. Is there anything that can be done?

These are great points. I personally consider import files a necessary 
evil. There are a couple of things that make me hopeful about 
simplifying the situation:

a) D parses fast enough to allow importing extensive modules;

b) The "no-hijack" approach allows liberal importing of modules without 
fear of serious name clashes.

Walter and I discussed quite a few times the possibility of defining 
std.all that publically imports all of std. My experiments show that a 
short script importing std.all will compile slower, but not too slow, 
compared to a script that only import a few modules.

One other possibility would be to define some generic modules that group 
together useful lower-level modules. The question is of course how to 
name those aggregation modules (std.common?) and what they should include.

Some PR or tips on how to search the documentation may also be helpful. 
If you navigate to Phobos' homepage 
http://digitalmars.com/d/2.0/phobos/phobos.html and then enter

conversion

in the search box, std.conv comes up first. Also, the same module comes 
up first if you search this with google:

d programming language conversion

It would be great to improve D and Phobos accessibility for first-time 
users.

(To my personal satisfaction, searching google for

std::algorithm

puts D's std.algorithm in the third or fifth position (depending how you 
count), after the obligatory C++ reference sites.)


Andrei
November 29, 2009
Re: Phobos packages a bit confusing
On Sun, Nov 29, 2009 at 07:12:50PM +0000, retard wrote:
> after using D1 and Tango for couple of years we decided to experiment 
> with D2 and Phobos in a small scale project. For some reason the mostly 
> flat package hierarchy seemed rather confusing.

Are you familiar with C's standard library? Phobos is loosely based on it,
so if you can think of where you'd find it in C, it won't be far off in phobos.

> Entities like 'stdin' seem to have no 
> documentation at all. What should I import to get it, what interfaces 
> does it implement etc.

http://digitalmars.com/d/2.0/phobos/std_stdio.html#File

stdin is just an instance of that struct - directly analogous to how stdin
in C is a FILE*. (D actually used C's FILE* directly for the longest
time.)

>  * std.string [the input was a string, maybe toInt is a string operation]

That's where it used to be, but now the generic to!() template
does it all, including non string types, so it gets its own module.

> I admit using higher level languages has made major damage to my brain 
> ("500.1".toInt anyone?), but still using Tango, Java, or C# seems rather 
> intuitive, but in Phobos the set of packages and their contents feels 
> more or less arbitrary. Is there anything that can be done?

I do think some more big picture overview like documentation pages would
be a good idea. If I had more time, I'd write some of them myself.

-- 
Adam D. Ruppe
http://arsdnet.net
November 29, 2009
Re: Phobos packages a bit confusing
== Quote from Andrei Alexandrescu (SeeWebsiteForEmail@erdani.org)'s article
> Walter and I discussed quite a few times the possibility of defining
> std.all that publically imports all of std. My experiments show that a
> short script importing std.all will compile slower, but not too slow,
> compared to a script that only import a few modules.

Vote++.  This would be a nice little convenience when writing small scripts in D,
which I actually do quite often because I already know where basic APIs like file
I/O are in Phobos and I don't want to learn another API just for small scripts.
This goes along with the scaling down thing I was talking about a few days ago.  A
well-designed language and library should be good for both big projects (making
complicated things possible) and small projects (making things simple).  std.all
would be a trivial addition that wouldn't clash with anything else and would
really help Phobos scale down better.
November 29, 2009
Re: Phobos packages a bit confusing
Sun, 29 Nov 2009 14:36:24 -0500, Jason House wrote:

> retard Wrote:
> 
>> Hi
>> 
>> after using D1 and Tango for couple of years we decided to experiment
>> with D2 and Phobos in a small scale project. For some reason the mostly
>> flat package hierarchy seemed rather confusing.
>> 
>> For instance, it took two of us 15 minutes to build a program that
>> reads a line from user, converts the string to a natural number, adds
>> one, and finally prints it to the screen. Entities like 'stdin' seem to
>> have no documentation at all. What should I import to get it, what
>> interfaces does it implement etc.
> 
> That's an interesting example considering how Tango IO is way more
> complex. Comparatively speaking, 15 minutes is great!
> 
> That being said, there probably are ways to make D2 Phobos easier to
> use.
> 
> 
> 
>> When writing this, I already forgot what package contained the to!
>> template.
> 
> std.conv (for conversions)
> 
> 
>> My intuition says it should be in
>>  * std.stdint [int related operations] * std.format [number formats?]
>>  * std.typecons [we're constructing a int from a string] * std.string
>>  [the input was a string, maybe toInt is a string operation] *
>>  std.numeric [it's a numeric operation, isn't it]
>> 
>> I admit using higher level languages has made major damage to my brain
>> ("500.1".toInt anyone?), but still using Tango, Java, or C# seems
>> rather intuitive, but in Phobos the set of packages and their contents
>> feels more or less arbitrary. Is there anything that can be done?
> 
> Any massively used language is easier to use because a google search
> turns up similar code. I've found both D2 Phobos and Tango to be easy to
> use once you start. Tango was easier to find where most things were, but
> was amazingly tough to assemble generic pieces for IO. I remember
> reading line buffered text from standard in was way simpler with D2
> Phobos.

Agreed. Also, once you start memorizing stuff, it doesn't matter that 
much anymore what the functions are called and where they can be found.  
I found the tutorials on Tango's site very helpful when learning it. I 
also agree that doing common tasks is more straightforward with Phobos 
and the resulting code is also a bit shorter, but using Tango was a bit 
more intuitive.
November 29, 2009
Re: Phobos packages a bit confusing
Sun, 29 Nov 2009 20:26:07 +0000, dsimcha wrote:

> == Quote from Andrei Alexandrescu (SeeWebsiteForEmail@erdani.org)'s
> article
>> Walter and I discussed quite a few times the possibility of defining
>> std.all that publically imports all of std. My experiments show that a
>> short script importing std.all will compile slower, but not too slow,
>> compared to a script that only import a few modules.
> 
> Vote++.  This would be a nice little convenience when writing small
> scripts in D, which I actually do quite often because I already know
> where basic APIs like file I/O are in Phobos and I don't want to learn
> another API just for small scripts. This goes along with the scaling
> down thing I was talking about a few days ago.  A well-designed language
> and library should be good for both big projects (making complicated
> things possible) and small projects (making things simple).  std.all
> would be a trivial addition that wouldn't clash with anything else and
> would really help Phobos scale down better.

When writing small scripts, I use bpython:

http://www.bpython-interpreter.org/screenshots/

Nicely integrated apidocs.
November 29, 2009
Re: Phobos packages a bit confusing
Sun, 29 Nov 2009 15:30:14 -0500, Adam D. Ruppe wrote:

> On Sun, Nov 29, 2009 at 07:12:50PM +0000, retard wrote:
>> after using D1 and Tango for couple of years we decided to experiment
>> with D2 and Phobos in a small scale project. For some reason the mostly
>> flat package hierarchy seemed rather confusing.
> 
> Are you familiar with C's standard library? Phobos is loosely based on
> it, so if you can think of where you'd find it in C, it won't be far off
> in phobos.

Nope, I come from Java/C# land.

> 
>> Entities like 'stdin' seem to have no documentation at all. What should
>> I import to get it, what interfaces does it implement etc.
> 
> http://digitalmars.com/d/2.0/phobos/std_stdio.html#File

> stdin is just an instance of that struct - directly analogous to how
> stdin in C is a FILE*. (D actually used C's FILE* directly for the
> longest time.)

I got it now. Note that stdin and stdout aren't defined anywhere. They're 
mentioned only briefly in the examples of the informal documentation.
November 29, 2009
Re: Phobos packages a bit confusing
== Quote from retard (re@tard.com.invalid)'s article
> Sun, 29 Nov 2009 20:26:07 +0000, dsimcha wrote:
> > == Quote from Andrei Alexandrescu (SeeWebsiteForEmail@erdani.org)'s
> > article
> >> Walter and I discussed quite a few times the possibility of defining
> >> std.all that publically imports all of std. My experiments show that a
> >> short script importing std.all will compile slower, but not too slow,
> >> compared to a script that only import a few modules.
> >
> > Vote++.  This would be a nice little convenience when writing small
> > scripts in D, which I actually do quite often because I already know
> > where basic APIs like file I/O are in Phobos and I don't want to learn
> > another API just for small scripts. This goes along with the scaling
> > down thing I was talking about a few days ago.  A well-designed language
> > and library should be good for both big projects (making complicated
> > things possible) and small projects (making things simple).  std.all
> > would be a trivial addition that wouldn't clash with anything else and
> > would really help Phobos scale down better.
> When writing small scripts, I use bpython:
> http://www.bpython-interpreter.org/screenshots/
> Nicely integrated apidocs.

Yeah, I like Python, especially for things where I need tons of libraries that
have simple APIs and are just there, or where I really need a dynamic language and
even D templates aren't a good substitute.  I do most of my coding in D, with
Python as my second language for when D is just the wrong tool for the job.  However,

1.  I'm more used to D and it's almost as easy to use as Python.  Therefore I tend
to use D more for the "grab the quickest thing available and get it working" kind
of programming.

2.  I sometimes need to write tiny but fast programs, such as simple monte carlo
simulations that I want to be able to tweak and run with as little thumb twiddling
in between as possible, or utility programs that do some specific operation to a
large amount of data.  Since D's build times are negligible for these programs and
D code runs much faster than Python, D is the better tool here.

3.  I've built up a whole bunch of custom libraries in D that I like (the
better/more universally useful ones I've released under various projects, the more
quick and dirty or niche ones I haven't) and I want access to them even in very
small scripts.
November 29, 2009
Re: Phobos packages a bit confusing
dsimcha wrote:
> == Quote from Andrei Alexandrescu (SeeWebsiteForEmail@erdani.org)'s article
>> Walter and I discussed quite a few times the possibility of defining
>> std.all that publically imports all of std. My experiments show that a
>> short script importing std.all will compile slower, but not too slow,
>> compared to a script that only import a few modules.
> 
> Vote++.  This would be a nice little convenience when writing small scripts in D,
> which I actually do quite often because I already know where basic APIs like file
> I/O are in Phobos and I don't want to learn another API just for small scripts.
> This goes along with the scaling down thing I was talking about a few days ago.  A
> well-designed language and library should be good for both big projects (making
> complicated things possible) and small projects (making things simple).  std.all
> would be a trivial addition that wouldn't clash with anything else and would
> really help Phobos scale down better.

Sounds great. I'm even more encouraged by some brief measurement 
results. I timed dmd against this program:

void main(){}

Then against this program:

import std.stdio;
void main(){}

Then against this program:

import std.stdio;
void main(){}

For convenience of other testers I'm pasting std.all after this message.

The test machine is a 2.5 years old bottom-of-the-line Ubuntu laptop 
that seems to be in possession of the secret of immortality. Quiescent 
average run times:

* 0.23 seconds for the first program

* 0.64 seconds for the second program

* 0.98 seconds for the third program

I assume any program or script would have to include at least one 
module, and the marginal cost of including all other modules is low 
enough to be encouraging.

Andrei


module std.all;

public import std.algorithm;
public import std.array;
//public import std.atomics;
public import std.base64;
public import std.bigint;
public import std.bitmanip;
public import std.boxer;
public import std.compiler;
public import std.complex;
public import std.contracts;
public import std.conv;
public import std.cpuid;
public import std.cstream;
public import std.ctype;
public import std.date;
public import std.datebase;
public import std.dateparse;
public import std.demangle;
public import std.encoding;
public import std.file;
public import std.format;
public import std.functional;
public import std.getopt;
public import std.intrinsic;
public import std.iterator;
public import std.json;
//public import std.loader;
public import std.math;
public import std.md5;
public import std.metastrings;
public import std.mmfile;
public import std.numeric;
public import std.outbuffer;
public import std.path;
public import std.perf;
public import std.process;
public import std.random;
public import std.range;
public import std.regex;
public import std.regexp;
public import std.signals;
public import std.socket;
public import std.socketstream;
public import std.stdint;
public import std.stdio;
public import std.stdiobase;
public import std.stream;
public import std.string;
public import std.syserror;
public import std.system;
public import std.traits;
public import std.typecons;
public import std.typetuple;
public import std.uni;
public import std.uri;
public import std.utf;
public import std.variant;
public import std.xml;
public import std.zip;
public import std.zlib;
« First   ‹ Prev
1 2 3 4 5
Top | Discussion index | About this forum | D home