On Sunday, 28 January 2018 at 13:50:03 UTC, Michael wrote:
> On Friday, 26 January 2018 at 09:02:03 UTC, Ola Fosheim Grøstad wrote:
>> While this analysis of language popularity on Github is enlightening:
>>
>> http://www.benfrederickson.com/ranking-programming-languages-by-github-users/
>>
>> I found the older analysis of how programmers transition (or adopt new languages) more interesting:
>>
>> https://blog.sourced.tech/post/language_migrations/
>>
>> Like how people move from Rust to Go. And from Go to Python:
>>
>> https://blog.sourced.tech/post/language_migrations/sum_matrix_22lang_eig.svg
>>
>>
>> Also the growth of Java is larger than I would anticipate:
>>
>> https://blog.sourced.tech/post/language_migrations/eigenvect_stack_22lang.png
>>
>> Granted, Java has gotten quite a few convenience features over the years.
>
> I find it fascinating that C# is in the "languages to avoid" section, because from my perspective it's receiving more and more adoption as the modern alternative to Java, in a way that Go and Rust are not. Different markets and all of that. So I can't see why C# would be seen as a language that is dropping in popularity (though I don't use it myself).
>
> I do worry that, having been using D for about 3 1/2 years now, that the perceptions of D outside of this community don't seem to be changing much. It does seem to make a huge difference to have a big company behind a language, purely for the "free advertisement". Most people at my university, outside of the computer science department, that are using languages like Python and R and MATLAB the most, are very aware of Rust and Go, but not D. I wonder if we do need to pay more attention to attracting new users just to get people talking about it.

This has been mentioned multiple times, D really needs some kind of killer application.

On my line of work having Go on the skills list is slowly becoming a requirement, due to Docker and Kubernetes adoption on cloud infrastructures.

The new OpenGL debugger for Android from Google has been re-written in Go.

Go and Rust are also having a relevant role in Fuchsia, e.g. the TCP/IP stack is 100% Go code.

The new regexp engine from Visual Studio Code is written in Rust.

The Go plugin for Visual Studio Code is written by Microsoft themselves.

D has PowerNex as an example OS, but Redox looks more pleasing to the eye, in what concerns attracting new developers to the project.

Just wondering if mir or easier GPGPU programming could be that killer application.

On Sunday, 28 January 2018 at 13:50:03 UTC, Michael wrote:
> I do worry that, having been using D for about 3 1/2 years now, that the perceptions of D outside of this community don't seem to be changing much. It does seem to make a huge difference to have a big company behind a language, purely for the "free advertisement". Most people at my university, outside of the computer science department, that are using languages like Python and R and MATLAB the most, are very aware of Rust and Go, but not D. I wonder if we do need to pay more attention to attracting new users just to get people talking about it.

That's what you would expect, because D is a very ambitious language, which means its natural user base is much more spread out and less highly concentrated.  And beyond that, most code is enterprise code that's closed source, and whilst the web guys talk a lot and influence the culture, enterprise guys talk much less and just do their thing quietly.  Even in our world, how often do you see the people using D get involved in forum discussions?  Sociomantic, Weka, Ebay, and so on.  (Or Microsoft - did you know that D was used in their COM team?  They didn't exactly send out a press release...)  A little bit, but only a little in relation to their use of the language.  If you're trying to accomplish something in a representative enterprise context with lean resources, you don't have much time to talk about what you are doing.

If you want to draw people to the language (and, honestly, I wonder why it matters so much to many here - it's clearly taking hold, has momentum and will continue to grow for decades; an acorn will become an oak tree, and fretting about how much it's grown in the past year might be missing the point, so long as it's healthy enough), why not just focus on both improving the language itself (pull requests, documentation) and on accomplishing something useful and worth doing with it?

Of course there are the usual trolls who don't seem to write much D, but seem to be drawn like vampires to the energy of those who do.  Sad.




On Sunday, 28 January 2018 at 17:23:12 UTC, Paulo Pinto wrote:
> This has been mentioned multiple times, D really needs some kind of killer application.

Why?

It's a generalist language for getting stuff done in an age where people have succumbed so much to Stockholm Syndrome that they think it's a positive thing in a language that you can only use it to do something special.  Yet trends in performance and performance demands point to the rising importance of efficiency (and I suspect there will be a return to the recognition of the importance of being a generalist - in programming, as in other fields).  There was a tweet by the author of Musl libc observing that software today runs slower than software twenty years ago, and linking the bloat to the insane pressure to maximise CPU performance over all else.  The era of that kind of ruthless optimization is over because it's not the only thing that matters, and we start to see the price of it.  And generalism - in a dynamic business environment, there's considerable value to have capabilities that aren't adapted to particular narrow skills when what you need is always changing and may be unknown even to you.

My generation was privileged because very quickly if you wanted to get anything interesting done you had to learn assembly language (maybe write your own assembler or disassembler), had to learn a bit about hardware, and could never pretend the CPU was this perfect platonic abstraction.  And for a while that changed, but I think the past is returning again, as it often does.

So I see a value in hiring hacker / generalist types who can figure things out.  For example:

https://hackaday.com/2017/01/26/a-personal-fight-against-the-modern-laptop/
https://www.youtube.com/watch?v=Fzmm87oVQ6c

Back in 2007, most finance types would have said how completely impracticable and unreasonable.  But I say, with GK Chesterton, that "all progress depends on the unreasonable man".  And someone like that doesn't succumb to helplessness once they are outside of their shiny IDE, knows that in the end everything is just code, and you can change it if you want to, and there is strategic value from building organisational capabilities from hiring such people.  Usually I'm a couple of years ahead, and I think others will follow.  If you hold a contrarian point of view, you know you're right when surprises start coming in your direction, and people still can't see it.  And I think that's been the case since 2014.

Anyway - so D is a general purpose language, and I think we are likely seeing a nascent return in recognizing the value of generalist tools and people.

> On my line of work having Go on the skills list is slowly becoming a requirement, due to Docker and Kubernetes adoption on cloud infrastructures.

That's great.  Walter says that good code should look good on the page, and Go code looks nice enough.  It's got nice network and infra libraries, as you say.  But why would the adoption of Go be bad for D?  I think it's great for D because after a period of stagnation it gets people open to newer languages, and on the other hand the gap between the spirit of Go and D isn't that far (GC, clean code, native target) even if they don't have generics.  It's a big world - both D and Go can succeed, and the success of one isn't bought at the cost of the other.

> Just wondering if mir or easier GPGPU programming could be that killer application.

We sponsor mir algorithm (some of the routines within were developed for us, and we were happy to open source them), and we are rewriting our core analytics - used across the firm in a $4.1bn hedge fund in D from C++ before that.  What alternative really exists for what we are doing there?  And C++ vs D, it's not even a fair fight if you care about productivity, plasticity of the code, and generating wrappers for other languages that you can still understand whilst maintaining decent performance.  At the same time, we're not a D shop - a diversity of languages is not a bad thing, provided you have some way for them to work together.  Code reuse is very difficult, but the UNIX way does work.  On the other hand, if you want to connect components, how are you to do that?  Well, D is pretty nice for writing DSLs that can connect to code written in other languages, and where expressions can be evaluated from other languages.

A specialist language adapted to a particular domain or set of domains - yes, that benefits from a killer app.  But for a generalist language that's useful for getting stuff done - why would there be a single killer app?  That doesn't make sense to me.  There should be multiple successes across different domains, and that's what we are beginning to see.  Just bear in mind that the web and tech guys talk a lot, but most programmers don't work in those industries.  It would be a mistake to conflate salience with economic importance, I think.


Laeeth.

On Sunday, 28 January 2018 at 13:50:03 UTC, Michael wrote:
> I find it fascinating that C# is in the "languages to avoid" section, because from my perspective it's receiving more and more adoption as the modern alternative to Java, in a way that Go and Rust are not. Different markets and all of that. So I can't see why C# would be seen as a language that is dropping in popularity (though I don't use it myself).

I don't think the data suggests that? A small dip, perhaps, as it is less relevant outside Microsoft desktop. But the transition matrix suggests that people move a bit between Java and C# and that people move from Pascal and Visual Basic to C#.

I suspect some projects move from C# to TypeScript, though.

> I do worry that, having been using D for about 3 1/2 years now, that the perceptions of D outside of this community don't seem to be changing much.

But D isn't changing either...

On Sunday, 28 January 2018 at 15:36:17 UTC, bachmeier wrote:
> On Sunday, 28 January 2018 at 13:50:03 UTC, Michael wrote:
>> Most people at my university, outside of the computer science department, that are using languages like Python and R and MATLAB the most, are very aware of Rust and Go, but not D.
>
> I'd say Julia is getting a lot more attention than Rust or Go for those users. And rightfully so.

I wasn't trying to relate these two sections. My point above was that people who don't really work with systems languages were still widely aware of the existence of new languages, while D remains relatively obscure.

>
>> I wonder if we do need to pay more attention to attracting new users just to get people talking about it.
>
> I'm not sure why those users would be interested in D at the moment. D presents itself as a C++ replacement, discussions are all about low-level stuff, garbage collection, and efficiency, and new users are told to use Dub and learn about Git submodules. That's not ever going to appeal to the R and Matlab crowd. I have gotten others to start using D, and it was quite easy. Just make an R package containing D code, they install it, and then they call D functions from R. Few in this community understand that style of programming though.

But D is fighting against Rust and Go, and struggling to pull any attention away from either. Go has found its niche, and has settled pretty well, but it has not been overwhelmingly adopted by the whole target audience. Rust, on the other hand, seems to be picking up those who have left Go.

On Sunday, 28 January 2018 at 23:09:00 UTC, Michael wrote:
> by the whole target audience. Rust, on the other hand, seems to be picking up those who have left Go.

I guess some go to Rust after working with Go, but the transition matrix linked above suggests that the trend has been that people give up on Rust and try out Go then Python... Of course, with so little data things are uncertain and can change.

On Monday, 29 January 2018 at 03:22:54 UTC, Ola Fosheim Grøstad wrote:
> On Sunday, 28 January 2018 at 23:09:00 UTC, Michael wrote:
>> by the whole target audience. Rust, on the other hand, seems to be picking up those who have left Go.
>
> I guess some go to Rust after working with Go, but the transition matrix linked above suggests that the trend has been that people give up on Rust and try out Go then Python... Of course, with so little data things are uncertain and can change.

It would probably be informative to get the raw data and see how the transition matrix looks for D. Are people (or rather github users) coming to D from C/C++ or from other languages. Would help inform strategy for getting new users or why people from certain languages are less likely to try D.

On Monday, January 29, 2018 04:18:12 jmh530 via Digitalmars-d wrote:
> On Monday, 29 January 2018 at 03:22:54 UTC, Ola Fosheim Grøstad
>
> wrote:
> > On Sunday, 28 January 2018 at 23:09:00 UTC, Michael wrote:
> >> by the whole target audience. Rust, on the other hand, seems to be picking up those who have left Go.
> >
> > I guess some go to Rust after working with Go, but the transition matrix linked above suggests that the trend has been that people give up on Rust and try out Go then Python... Of course, with so little data things are uncertain and can change.
>
> It would probably be informative to get the raw data and see how the transition matrix looks for D. Are people (or rather github users) coming to D from C/C++ or from other languages. Would help inform strategy for getting new users or why people from certain languages are less likely to try D.

It would be interesting to know, but I question how valid the conclusions are just getting information from github like that. For instance, I came from C++ to D. However, I never used github before D's developement moved to github, and their methodology would show me as someone who used D almost exclusively and who did not switch from any other language. So, while I'm sure that some valid conclusions can be taken from the data, it's going to be skewed by the fact that not everything a programmer does or has done ends up on github.

- Jonathan M Davis

On Monday, 29 January 2018 at 04:58:49 UTC, Jonathan M Davis wrote:
>
> It would be interesting to know, but I question how valid the conclusions are just getting information from github like that. For instance, I came from C++ to D. However, I never used github before D's developement moved to github, and their methodology would show me as someone who used D almost exclusively and who did not switch from any other language. So, while I'm sure that some valid conclusions can be taken from the data, it's going to be skewed by the fact that not everything a programmer does or has done ends up on github.
>
> - Jonathan M Davis

I don't deny that there are limitations to the data. At best, it would be telling you the transition of github users over a specific period.

On Mon, 2018-01-29 at 03:22 +0000, Ola Fosheim Grøstad via Digitalmars-
d wrote:
[…]
> I guess some go to Rust after working with Go, but the transition matrix linked above suggests that the trend has been that people give up on Rust and try out Go then Python... Of course, with so little data things are uncertain and can change.

I think this is an important point. There was some interesting data found, some hypotheses possible, but without further experimentation and/or formal use of Grounded Theory exploration, all commentary is speculation and opinion.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Sun, 2018-01-28 at 18:54 +0000, Laeeth Isharc via Digitalmars-d
wrote:
[…]
> That's what you would expect, because D is a very ambitious language, which means its natural user base is much more spread out and less highly concentrated.  And beyond that, most code is enterprise code that's closed source, and whilst the web guys talk a lot and influence the culture, enterprise guys talk much less and just do their thing quietly.  Even in our world, how often do you see the people using D get involved in forum discussions?  Sociomantic, Weka, Ebay, and so on.  (Or Microsoft - did you know that D was used in their COM team?  They didn't exactly send out a press release...)  A little bit, but only a little in relation to their use of the language.  If you're trying to accomplish something in a representative enterprise context with lean resources, you don't have much time to talk about what you are doing.
> 
> If you want to draw people to the language (and, honestly, I wonder why it matters so much to many here - it's clearly taking hold, has momentum and will continue to grow for decades; an acorn will become an oak tree, and fretting about how much it's grown in the past year might be missing the point, so long as it's healthy enough), why not just focus on both improving the language itself (pull requests, documentation) and on accomplishing something useful and worth doing with it?

Go was ambitious, but grew more like a Cypress than an Oak. Many reasons, we have mulled over this a number of time already. As I remember the main ones:

0. Hype.
1. Timing.
2. Marketing.
3. Simple language that Google interns can use and not make errors.
4. Documentation.
5. Good standard library.
6. Ability to work with Git, Mercurial, and Bazaar repositories as
dependencies.
7. Documentation.
8. Funded support.
9. It replaces C. But then so does Rust.

Of course there were problems:

0. No way of doing complex repeatable builds.
1. The Web absorbs all.

There is a lot of proprietary as well as FOSS Go code. Ditto Java, C++. But FOSS is where the marketing is and where many of the proprietary decisions on programming language are made.

One thing that Go got almost right was the way of using FOSS packages and libraries. Rust, via Cargo, did a much better job. Go has a small standard library and allows use of any DVCS, there is no central contributed system. Rust/Cargo has a small standard library, a central contributed library, and the ability to use arbitrary DVCS. Rust/Cargo wins on this hands down. I suggest Dub needs more work to be like Cargo. This and documentation strike me as the most important things for the evolution of D.

> Of course there are the usual trolls who don't seem to write much D, but seem to be drawn like vampires to the energy of those who do.  Sad.

:-)

> On Sunday, 28 January 2018 at 17:23:12 UTC, Paulo Pinto wrote:
> > This has been mentioned multiple times, D really needs some kind of killer application.
> 
> Why?

s/killer// and you get a better measure. D needs more applications out there to act as exemplars. Currently we have Tilix and…

> It's a generalist language for getting stuff done in an age where people have succumbed so much to Stockholm Syndrome that they think it's a positive thing in a language that you can only use it to do something special.  Yet trends in performance and performance demands point to the rising importance of efficiency (and I suspect there will be a return to the recognition of the importance of being a generalist - in programming, as in other fields).  There was a tweet by the author of Musl libc observing that software today runs slower than software twenty years ago, and linking the bloat to the insane pressure to maximise CPU performance over all else.  The era of that kind of ruthless optimization is over because it's not the only thing that matters, and we start to see the price of it.  And generalism - in a dynamic business environment, there's considerable value to have capabilities that aren't adapted to particular narrow skills when what you need is always changing and may be unknown even to you.

I am less convinced by this argument. Go, Rust, and especially Java have shown the power of tribalism and belonging to the one true tribe eschewing all others. Java is a superb example of this: the JVM is now a polyglot platform, and yet Java programmers, especially enterprise ones, will only contemplate using Java and refuse to be educated about Kotlin, Ceylon, Groovy, JRuby, etc. However when a feature inspired (many years later) by the innovations in other JVM-based languages gets shoehorned into Java then, eventually, the Java folk are prepared, reluctantly, to learn about it. And maybe a few years later actually use it.

> My generation was privileged because very quickly if you wanted to get anything interesting done you had to learn assembly language (maybe write your own assembler or disassembler), had to learn a bit about hardware, and could never pretend the CPU was this perfect platonic abstraction.  And for a while that changed, but I think the past is returning again, as it often does.

FORTRAN, the one true way. Who needs the intricacies of assembly language when you have FORTRAN. :-)

> So I see a value in hiring hacker / generalist types who can figure things out.  For example:
> 

All companies should. Expertise in programming is not length of time on one language, but the number of different computational models you can work with to a reasonable quality of code.

Obviously familiarity with a set of needed API can be a help to speed of getting a new person productive in a given project, but that is learnable.


> Back in 2007, most finance types would have said how completely impracticable and unreasonable.  But I say, with GK Chesterton, that "all progress depends on the unreasonable man".  And someone like that doesn't succumb to helplessness once they are outside of their shiny IDE, knows that in the end everything is just code, and you can change it if you want to, and there is strategic value from building organisational capabilities from hiring such people.  Usually I'm a couple of years ahead, and I think others will follow.  If you hold a contrarian point of view, you know you're right when surprises start coming in your direction, and people still can't see it.  And I think that's been the case since 2014.
> 
> Anyway - so D is a general purpose language, and I think we are likely seeing a nascent return in recognizing the value of generalist tools and people.

It never really went away, we just had a period of PHP, JavaScript,
HTML, and CSS being all there was as far as people with money to fund
stuff were concerned.

> > On my line of work having Go on the skills list is slowly becoming a requirement, due to Docker and Kubernetes adoption on cloud infrastructures.
> 
> That's great.  Walter says that good code should look good on the
> page, and Go code looks nice enough.  It's got nice network and
> infra libraries, as you say.  But why would the adoption of Go be
> bad for D?  I think it's great for D because after a period of
> stagnation it gets people open to newer languages, and on the
> other hand the gap between the spirit of Go and D isn't that far
> (GC, clean code, native target) even if they don't have generics.
>   It's a big world - both D and Go can succeed, and the success of
> one isn't bought at the cost of the other.

And Go has channels and task pools.

Whilst David Simcha did a lot of work on tasks and task pools for std.parallelism, it only really addresses data parallelism. I think there needs to be some work within std.concurrency and std.parallelism to have a single task structure and "thread pool" system. That Go had this from the outset is a Good Thing™. Go does this at the language level. D does it at the standard library level. Rust has gone one further and has a low-level thread and channel system in the language and standard library, everything else is in a separate library. This raises the question of whether Phobos should be broken up.

Python originally had the "batteries included" view of it's standard library, and continues to suffer problem because of trying to retain this. PyPI and pip have removed the need for much of the standard library. I am beginning to think that D needs a smaller standard library (Phobos) and a better package system (Dub) taking lessons from Rust and Cargo.

> > Just wondering if mir or easier GPGPU programming could be that killer application.
> 
> We sponsor mir algorithm (some of the routines within were developed for us, and we were happy to open source them), and we are rewriting our core analytics - used across the firm in a $4.1bn hedge fund in D from C++ before that.  What alternative really exists for what we are doing there?  And C++ vs D, it's not even a fair fight if you care about productivity, plasticity of the code, and generating wrappers for other languages that you can still understand whilst maintaining decent performance.  At the same time, we're not a D shop - a diversity of languages is not a bad thing, provided you have some way for them to work together.  Code reuse is very difficult, but the UNIX way does work.  On the other hand, if you want to connect components, how are you to do that?  Well, D is pretty nice for writing DSLs that can connect to code written in other languages, and where expressions can be evaluated from other languages.
> 
> A specialist language adapted to a particular domain or set of domains - yes, that benefits from a killer app.  But for a generalist language that's useful for getting stuff done - why would there be a single killer app?  That doesn't make sense to me.  There should be multiple successes across different domains, and that's what we are beginning to see.  Just bear in mind that the web and tech guys talk a lot, but most programmers don't work in those industries.  It would be a mistake to conflate salience with economic importance, I think.

I agree we do not need "a killer app", but we do "exemplar apps", Tilix is one, but more are needed. Also better documentation. I still find the documentation for Phobos impenetrable most of the time. And the documentation for GtkD and GStreamerD tells us about the C API not the D binding. It clearly needs effort over and above what is being provided, and there is no resource, so in all likelihood nothing will change.


-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk