On Tuesday, 14 August 2018 at 07:05:12 UTC, Joakim wrote:
On Tuesday, 14 August 2018 at 02:49:58 UTC, Mike Franklin wrote:
On Monday, 13 August 2018 at 09:50:29 UTC, Joakim wrote:
Announced last week, the Nim team will be adding two
full-time paid devs and setting up grants for needed projects
with this new funding:
:jealous:
However, there are other ways to raise funds. Companies using
D could use the existing bountysource page to put up bounties
for features/fixes or projects they need, to which community
members who need some particular feature/fix could also
donate:
https://www.bountysource.com/teams/d
I think bountysource would work if the bounties were
significantly higher, but there are also the funding options
at https://opencollective.com/dlang
Yes, some of those bounties are too low for the amount of work,
but nothing stops others who find them important to increase
the bounty incrementally.
Looking on the right column of the page there are several D
enthusiasts contributing their hard-earned money to D. Maybe
there's a better option for the masses, besides a T-shirt and
a DConf discount, that might encourage more donors. For
example, I might contribute somewhere between $100 or more if
I could get some attention on some bugs/features that I care
about (assuming I couldn't implement them myself). Maybe I'll
post a bounty in the near future and see how it goes.
A variation on that appears to be in the cards, as they've said
there will be more funding targets:
https://forum.dlang.org/post/orvcznlvraunkksjd...@forum.dlang.org
I don't really care which website is used, bountysource or
opencollective or whatever, but the community is unlikely to
contribute unless they have a clear idea of where the money is
going, which bountysource does a better job of showing right
now.
Right now, I'm the only one I know of working on the #dbugfix
stuff, but I'm finding the bugs submitted this round
exceptionally difficult. I don't know if I'll succeed with a
fix this round (Sorry!), but contact me directly, or post an
announcement on the forum, if you have a bug that you're
willing to motivate with a financial contribution to the D
Foundation, and I'll personally take a look at it. I'm
generally only capable of fixing some of the more simple bugs,
as my skills and understanding of DMD are quite limited, but I
promise I'll try.
This is not about me: I personally don't have any blocker bugs
that I'm worried about. I'm concerned about the general pace of
D development: I don't think we're as focused or organized on
gathering resources as we should be. My preferred model is to
turn D into a partially proprietary product, but I guess the
core team doesn't like that approach:
https://forum.dlang.org/thread/okuzksqzczprvuklp...@forum.dlang.org
Back when I was a little kid decades ago, I had a neighbor who
used to build model trains in his garage, what he did in his
spare time. I remember seeing it then and being thrilled that
it snaked all over his work area. 99% of open source projects
are the "model trains" of software devs, something they work on
for fun in their spare time, and never get used widely.
To get into the 1% of OSS projects that are actually widely
used, you need some way to gather resources to grow the
project. There's the linux model where you get a bunch of
consulting and support companies to use you. There's the
llvm/clang model where you become a product in a large company,
part of their portfolio alongside proprietary products or
modules that pay the bills. There's the Firefox model where you
sell ads alongside the OSS product. There's new models where
you use crowdfunding sites like kickstarter or opencollective.
D has so far used very little of any of these models. This
project can give off the impression that it is simply a big
model train for Walter and Andrei, a hobby that they've retired
to work on. Instead, I'd like to see D much more widely used,
which means work needs to be done on gathering resources beyond
what the project has now.
Have you read Peter Thiel's Zero to One and seen his YouTube
talks on secrets etc?
He says what I have always believed. I think market share is a
legitimate approach if that's your cup of tea, but dominating a
niche is a much better one if it fits you. I personally just by
virtue of who I am as a person found that as a life strategy
having a very high appeal to a tiny minority of people suits me
by far better (I like to think they are the best people but who
is really to say as it depends on your point of view).
I truly don't think it's relevant what most people think of D at
this point. The world is a very big place and there's room for
many languages and I don't think there will be another C - that
was a creature of its time, and time and conditions have changed
since then.
Most code is enterprise code that nobody much hears about and I
guess most programmers are paid to work on enterprise code. The
tech guys get an inordinate share of attention because of social
reasons and because the nature of their business fits with
talking much more about what they are doing. But I don't think
they represent a majority of the code that's written.
D is a very practical language and that means it's quite a good
tool for enterprise users if such users are at this point rather
unusual sorts of people able to make up their own minds in the
absence of marketing and advice from consultants - they also need
to be people that have the authority to decide to do what's best
without persuading a committee.
We are in an age that doesn't tend to be very patient about
enduring temporary discomfort - with D the discomfort is all
upfront. So you need to be both imaginative to see the longer
term benefits and an unusual sort of person to press through the
early discomfort. This makes D a great hiring filter if you are
at the stage of business development where we are today, but it's
not going to convince many pointy-headed bosses. So much the
worse for the pointy-headed bosses.
People are using D to do real work. As people do that they
naturally need to make improvements, and why wouldn't you open
source those ?
The way a broader audience comes to D will be as a result of
early successes and because of the calibre of the people that are
earlier adopters of D. And more importantly because of the
calibre of people in the D community. Throw a stone at dconf -
if you hit a bad programmer you probably missed and hit someone
from a different conference in the adjacent ballroom. In the
outside world things are not always like that.
If you want D to be more widely used then focus on what can be
done to help the people who are already using it in a small way
to succeed and use it further, and help people who want to use it
and almost can but face impediments that might not be difficult
to overcome but are from where they are sitting.
It's much better to focus on what's to hand and growing steadily
than to worry about trying to get D to a certain stage of
popularity. These things aren't under human control. The setup
must be there but then things happen when a bunch of conditions
inside and out come together all at the same time.
There's a magic when someone solves their own problem that's real
for them.
Goldman Sachs have their own internal languages for charting and
analysing data. Pretty good stuff for the 1990s but they had a
whole team working on them full-time.
Me, I wanted a DSL too for similar if more nuanced reasons, but
my resources were considerably less. Some of my evenings and
weekends and a couple of very talented part-time developers. I
knew of Pegged and had played with it, but it didn't become that
vivid that it wouldn't be that bad to write the whole thing till
I had dinner with Bastian at dconf.
Why bother writing a DSL? Because it's by far easier to register
types and functions of existing code and not just D code but C#
and Python. And one can impose restrictions that don't reduce
power much but make integration of various codebases and services
across the firm much easier.
I wrote it for one purpose and turns out it's useful for others I
never even thought of. Our risk reports across the firm are being
rewritten in it and now I'm wondering about accounting. I
actually wrote it originally to do what Bloomberg custom
expressions should perform but never will.
Anyway that's the path to it being used more I think. People you
have never heard of adopting it in a small way and then in a
larger way and then sharing their experiences with others.
I don't even want to think about the time I spent manually
translating headers for C libraries. Now with DPP that's no
longer a problem. In time it will probably work for C++
libraries too.
The barrier to introducing D into an existing C codebase just
keeps coming down.
I use EMSI containers. They at least downloaded excel-d. So
there's a positive spillover dynamic already underway. Give it
time and the consequences will become more evident.
