On Sunday, 5 June 2016 at 09:54:53 UTC, Artem Tarasov wrote:
I've learned about the last one only from this thread, and the
first two are listed only on http://wiki.dlang.org/
Scripting_Libraries, thus I draw the conclusion that's how they
are used most often.
One area where I do agree with you is that D hides it's light
under a bushel. Unless one is willing to look for them, there
are many hidden gems that aren't easy to learn about from the
front page (or the obvious links off that).
So I do think the idea of creating some channels per typical use
case would be a good one. I would help with that, but I
simply have no time for now, though it might change in a few
months. Possibly it's something the D Foundation could look at
once it's fully up and running.
Wrt PyD usage, not every project happens on GitHub in public, and
it may well be the case that commercial users don't open-source
code that uses PyD. I use it a little and haven't put stuff up
on github for that for the time being. But the functionality is
there - took a quick look just recently for another reason, and
last commit was no more than 4 days ago. Code base could
be cleaned up a little, as could the docs, but it works and I
think the cleanup will happen at some point. For OS X, not
sure if the shared library problem is relevant (I don't use a
Mac), but I know that John uses a Mac, so I expect it works with
dmd.
Have you seen any problems with multithreading in PyD? Ie have
you any reasons to be concerned? Obviously on the python
side there is the GIL, but I don't understand well enough any
complications posed by using shared libraries for threading -
I am not aware of any problems with PyD and threads though.
Re tiny druntime, that might suit you, but I think many people
would prefer that it's one simple import and, after all, you are
not actually using it. Probably Benjamin Thaut or others will
know the real resource cost of initializing D runtime on multiple
occasions (I presume it won't crash, but haven't tried, and I
imagine the cost is small if any).
Your point 1 sounds like a minor change rather than something
existential. I'll ask John Colvin.
Well, it's not for me, I'm mostly out already, back to
C++14/Python, after careful weighing of offerings w.r.t.
infrastructure /pain of coding.
Well, fair enough. Knuth welcomed the proliferation of languages
because language reflects thought and people think differently.
A language like D at this stage shouldn't try to cater to
everyone, because that's a recipe for spreading oneself too thin.
As Walter says, it is much better to cater to those who already
love the language and use it, and want to do more with it.
The ideal people for these kind of tasks are students, imho.
I think the whole point about D is that it is very helpful for
many purposes, and these can't be usefully captured by a single
abstract domain description.
For what it's worth, I am using it at the other extreme, for the
alternative investment management business. And it's already
used by a $20bn fund for absolutely critical functions, so I am
not sure that one can describe D as a language suited mostly to
the educational sphere, though I am sure it is useful there too.
It suits how I personally think, fits the problem domain well,
and the main costs are wrapping/porting libraries, and that is
a one-off cost that can be amortised over a larger project (set
off against quite substantial gains due to D's benefits).
I've read on this forum about some magic place where D is being
taught at a university, that's where I'd try to get an influx
from.
Seems to me that looking at metrics of growth there is hardly a
need to try to get an influx, and that also doesn't fit the
model of how D has developed - much more organically, where
people address their own pain, and by doing so open up the
language
for broader use (just like with bachmeier's work on D<->R.
dconf was 140+ people this year, and 40 in prior years. daily
downloads went from 200 odd in 2013 to 1300 odd
lately. compound growth is quite powerful.
Sorry to hear it doesn't fit what you want to do right now.
Maybe it just isn't for you. Or maybe you need more things to be
developed first and you should check back in a year.
But if one isn't making some people unhappy one is trying to be
all things to all people, and that's not a recipe for success
either. Given finite resources and no ability to tell people
what to do, I doubt the language would be in a better place if
people had worked on what you wished they had worked on rather
than what they did work on.
