== Quote from retard ([email protected])'s article > Sun, 29 Nov 2009 20:26:07 +0000, dsimcha wrote: > > == Quote from Andrei Alexandrescu ([email protected])'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.
