On Thursday, 2 July 2015 at 18:28:50 UTC, Russel Winder wrote:
On Tue, 2015-06-30 at 18:20 +0000, John Colvin via Digitalmars-d
-announce
 […]

Ditched distutils in favour of dub. This is easier for me to maintain and fits much better with the rest of the D ecosystem

I am not convinced by this, though cleary my feeling carry no weight in decision making :-)

For building C, and C++ extension (and indeed Chapel ones) it is assumed distutils will be used, allowing for:

        python3 setup.py build

        python3 setup.py install

SCons can do this but every one demands distutils. Can dub really replace distutils for installing extensions as well as building them? Will people installing extensions be prepared to switch to a non -standard system? Whilst perhaps they should, they won't. I fear that without a distutils installation, the extension will never be installed outside the development team. It's not the D community that must be convinced, it is the Python one.

What is the benefit from using distutils for working with D in a notebook? There are two standards - the Python one, and the D one. The advantage of using dub is that it becomes wonderfully easy to pull in D projects from code.dlang.org and to compile your own work developed under dub. (And dub itself continues to improve). Linking to a D project of decent complexity via distutils is not my idea of fun.

I do agree that for pyd itself it would be nice to retain the option of distutils (although I would love to see dub added also),

One should look at this as an alpha, extremely promising project. It is not any rough edges that are important at this stage, but that it has been done at all (in a form that is already very valuable).

The set of people that want to use computers to explore larger data sets than lately considered comfortable in an iterative manner is not small, even confining It just to finance. It's of real value to be able to hook in to a proper back end that manages market and static data, with also any data processing and analytics also in D, and then to have a pretty and friendly front end that can just talk to this code on the back with minimal messing around to get there. It's also very nice to have both Jupyter and an Excel spreadsheet at windows onto the data on your local machine or in the enterprise cloud.

The frictions to starting to play with D in a notebook are much lower than going via the command line, so I really am not sure if we should be worried about making it marketable at this stage rather than useful for doing real work. It's potentially a nice debugging tool where you are trying to make sense of things that don't tidily fit in a debugging window, and where there is just too much stuff to do it via writefln or logging without putting lots of effort into the infrastructure to find events first.

I do like the simpler syntax (than PyD). One question is whether you need to wrap every member of a struct.

But it's a very useful start as it stands.

Reply via email to