On Thursday, 2 July 2015 at 19:51:19 UTC, Laeeth Isharc wrote:
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.


This was my train of thought too.

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),

pyd does have rudimentary dub support, but it's only for embedding python in D, not the other way around. Extension support is on my TODO list, it's not complicated.

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.

@pdefRecursive!() or @pdef!(Recursive.yes) or @pdef!(Recursive) ? It's totally doable.

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

As an addendum: not many people prefer to do non system type things in C than a higher level language when time is money. So the mindset is you build a C extension to address the worst bits where Python's true colours shine through (ie when you are in a tight loop within Python interpreter and not spending most of the time in its C libraries. Or writing C glue to connect Python to another library.

In my view, D is different. I would rather write in D than Python, and to me it's much better Tor doing serious work. Even for parsing a CSV I prefer it (although one could debate the point). In any case D is not especially slower to write in than Python (particularly when you include time spent getting the bugs out), and in a decent number of cases it may be more productive.

So why bother with Python at all ? Better ecosystem for charting and exploring data, and an interpreter is better suited generally for certain kinds of tasks. Also in some areas more libraries, which can be helpful to get a quick result, so that one can go back and do it properly later.

Libraries, libraries, libraries. In a perfect world we can reimplement everything in D and it'll be awesome, but in the "getting shit done" world that normal people inhabit they need it to work, today. Bridges to other languages gives us that. E.g. I have a 3D plotting library in D (still in stealth mode on that one) that uses matplotlib via pyd to generate tick labels using either the builtin TeX parser & renderer (OK, fast) or actually calling out to latex (perfect, slow). Could I have done that all myself in D? Sure. Would I? No, i would still have terribly rendered tick labels with no TeX support. I don't have time to write a TeX implementation, even one as rudimentary and limited as matplotlib's.

In short, you're right.

It would be v helpful to have a Datetime conversion from D. Looks like there is a macro for converting from ymd in datetime.h, so I guess one could just write some code against this API in C, D, or Cython and link it in with D so one can transfer data structures over more easily.

I know just enough about that topic to be very scared.

Reply via email to