On Wednesday, 27 December 2017 at 16:38:35 UTC, Laeeth Isharc wrote:

>> A fair amount of D's design is based on psychology.
>
> I'd love to hear more about this sometime.

I never thought of this in the context of programming languages, but behavior is strongly modulated genetically, epi-genetically, and environmentally (this includes the social component).

Some of the forces modulating behaviors are terrifyingly powerful. Psycho-social biases and social forces are prime among those. So powerful they are that they can make individuals do things without even realizing. Conformity, obedience , influence, cognitive dissonance,  hundreds (Im not kidding) of social biases, in group / out group politics , pride, fear.

No one is immune not even the smartest of us and most exact of us. PhD to 8 classes only we are all influenced by those. Powerfully.

So it's not really exactly something unexpected that success of a programming language is powerfully modulated by this phenomena. Everything is. Including how you vote, what is your opinion on the right to bear weapon, on wars, on who is the friend and who is the enemy and
what is moral or imoral.

On Sunday, 24 December 2017 at 20:58:51 UTC, Russel Winder wrote:
> On Sun, 2017-12-24 at 17:13 +0000, Laeeth Isharc via Digitalmars-d wrote:
>> […]
>> 
>> New things grow at the fringes.  See the work of Clayton Christensen and his book the Innovator's Dilemma.  A head-on assault is ill-advised.  People looking for salvation are easier to talk to than those who don't see anything wrong with what they're doing currently.
>
> Not my experience in the JVM-related community, and to an extent the Python community, at least in the UK. Head on collisions create debate, and get you remembered. The debate generally leads to change, even if not the change initially envisaged. At least the status quo gets perturbed.
>
> Just dealing with the fringes and solving their problems rarely get serious traction. cf. Golo, Gosu, Fantom, Crystal, Pony, all of which solve definite problems but none of which have any serious traction to move programming on.

It's much better to have a monopoly of some niche or set of niches and to use energy from success to expand out from there, than to have a small market share of an enormous market.  And niche in this case is not something simple - it's people who have a certain set of kinds of problems and certain capabilities and who have the ability to make decisions on merits for them rather than primarily social factors.

See Peter Thiel's Zero to One for another expression of the same point.

From a strategic perspective, it's by far better for the challenger not to be taken seriously for the longest possible time until the moment is ripe, if it's possible to achieve that.

It takes a long time for a programming language to be adopted.  And the more ambitious the language, perhaps the longer it takes to mature and the longer it will be for it to achieve wide adoption.  D is a pretty ambitious language!

I can appreciate that if one's business involves teaching people a language then this is frustrating.  But I'd suggest taking a step back and looking at things from the point of view of the language itself, which is an organic creature not wholly under the control of its creators.  (See node.js).

On Wednesday, 27 December 2017 at 16:53:16 UTC, Dan Partelly wrote:
> On Wednesday, 27 December 2017 at 16:38:35 UTC, Laeeth Isharc wrote:
>
>>> A fair amount of D's design is based on psychology.
>>
>> I'd love to hear more about this sometime.
>
> I never thought of this in the context of programming languages, but behavior is strongly modulated genetically, epi-genetically, and ***environmentally** (this includes the social component).

Japanese cars were dismissed and laughed at for the longest time.  When the price of energy went bananas in the 1970s US auto makers were not laughing any more.  (And strategically it would have been terrible for the Japanese if US manufacturers had taken them seriously earlier).

So big relative price shocks have something to do with adoption.

https://www.quora.com/Python-programming-language-1/Why-is-Python-so-popular-despite-being-so-slow/answer/Laeeth-Isharc

https://queue.acm.org/detail.cfm?id=2874238

"For the entire careers of most practicing computer scientists, a fundamental observation has consistently held true: CPUs are significantly more performant and more expensive than I/O devices. The fact that CPUs can process data at extremely high rates, while simultaneously servicing multiple I/O devices, has had a sweeping impact on the design of both hardware and software for systems of all sizes, for pretty much as long as we've been building them.

***This assumption, however, is in the process of being completely invalidated.***
"

On Wed, 2017-12-27 at 16:57 +0000, Laeeth Isharc via Digitalmars-d wrote:
> 
[…]
> It's much better to have a monopoly of some niche or set of niches and to use energy from success to expand out from there, than to have a small market share of an enormous market.  And niche in this case is not something simple - it's people who have a certain set of kinds of problems and certain capabilities and who have the ability to make decisions on merits for them rather than primarily social factors.

Witness that it is likely that Kotlin will take over from Java as the primary language of Android application development.

In the end this is that the programming language offers something very significant to allow a change in the extant market leader.

> See Peter Thiel's Zero to One for another expression of the same point.
> 
>  From a strategic perspective, it's by far better for the
> challenger not to be taken seriously for the longest possible
> time until the moment is ripe, if it's possible to achieve that.

But the challenger must offer something that the extant market leader does not that the majority of the people in the game value. Without an obvious an unassailable value there will be no change in market leader.

> It takes a long time for a programming language to be adopted. And the more ambitious the language, perhaps the longer it takes to mature and the longer it will be for it to achieve wide adoption.  D is a pretty ambitious language!

Experimentally it takes 10 years for a language to achieve status these days. Exceptions prove the rule!

The challenger has to offer something that the community value. Rust offers memory safety over C. D offers "better C++". This is the wrong message to achieve traction. D must offer something that C++ does not offer.

> I can appreciate that if one's business involves teaching people a language then this is frustrating.  But I'd suggest taking a step back and looking at things from the point of view of the language itself, which is an organic creature not wholly under the control of its creators.  (See node.js).

But as of 2017-03-30 I have no hidden agenda, i.e. I retired. :-) This mjeans I am just doing what I want, which currently is organising ACCU conference, organising DevoxxUK conferences and programming DVB-T and DAB clients. D has failed to get traction at ACCU, has no chance at all at DevoxxUK, and has lost to Rust in DVB-T and DAB applications.

-- 
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 Sunday, 24 December 2017 at 21:27:12 UTC, Russel Winder wrote:
> On Sun, 2017-12-24 at 16:58 +0000, Laeeth Isharc via Digitalmars-d wrote:
>> Programming languages are tools for solving problems, and people face different problems and they also have different capabilities and tastes, which means even for people facing identical problems, the right tool for the job may not be the same because they aren't identical as groups and as individuals.
>
> Thinking of a programming language as a domain specific language for solving problems in a domain helps with this. Along with can a language enable creation of a DSL for solving my problems. Creating functions is creating a DSL in any language.

That's an extremely odd way to conceive of D, IMO, like conceiving of a banana as being like an apple, only it tastes like a banana and has a different shape.

If a general purpose programming language is to be conceived of as a domain specific language, what's the difference between a true domain specific language and a regular programming language?

That's really the whole point about D.  It's an era where people start out assuming that using the right tool for the job means that one tool can't do two different kinds of job well.  But, as Walter has said elsewhere I think, in some cases that's because the tools people are used to using are limited, whereas in fact there's no need for that - just use one tool that's good at both.  It's going to be a struggle to recognise such a tool if you start with the presumption it cannot exist.  And talking about languages as identical with DSLs only encourages this misconception, I think.


>> How does prestige develop?  From tangible consequences produced by able and virtuous people acting together to create something. There's a long lead time on that one, but it's not something that can be rushed.
>
> And sales and marketing. Arguably C was the last language that got traction based solely on technical benefit and tribalism. All other languages with traction since have had serious marketing behind them.

I don't think I suggested that tribalism in the everyday sense of the word is favourable to the adoption of a language.  But that aside, C is quite a big example, and I don't see that it has no relevance to the present, even though conditions are of course different.  Was Python adopted because of a big marketing budget?  If so, I didn't know that - who paid for it?  How about R?

I think you also need to consider consequences of beliefs if you are wrong and the choices available in circumstances (unless you can figure out how to create new choices).  You write as if adoption is flatlining.  It isn't - it's growing at a healthy pace, as best I can see.  Human perception doesn't deal very well with compound growth.  It's disappointing for a long time, and all of a sudden it's surprising.

It's by far best at this point to get across successful stories about the adoption of D to people who are already receptive to them because they have some problems that D might help with than to try to get people to listen to you who have no interest in listening.  Persuasion works when people are ready to move towards you.  You can't compel that.

On 12/27/2017 8:34 AM, Russel Winder wrote:
> On Tue, 2017-12-26 at 14:54 -0800, Walter Bright via Digitalmars-d
> wrote:
>> That's right. C++ is based on faith in the programmer using best
>> practices. D is
>> not based on faith, it can be automatically checked.
> 
> "Can be" is not the same as "is". Perhaps all D compilers should
> enforce the "can be" as "is", with options to switch it off if need be?

This illustrates my point if it was unclear:

C++:
    int foo(int* p) { return p[1]; }
    int bar(int i) { return foo(&i); }

    clang++ -c test.cpp -Wall


D:
    @safe:
    int foo(int* p) { return p[1]; }
    int bar(int i) {return foo(&i); }

    dmd -c test.d
    test.d(3): Error: safe function 'test.foo' cannot index pointer 'p'
    test.d(4): Error: cannot take address of parameter i in @safe function bar

On 12/27/2017 8:38 AM, Laeeth Isharc wrote:
> On Wednesday, 27 December 2017 at 07:44:30 UTC, Walter Bright wrote:
>> On 12/26/2017 4:18 AM, Russel Winder wrote:
>>> All of which brings us full circle: when it comes to programming
>>> languages and software development, it is all about advocacy,
>>> prejudice, and belief, there is very, very little science happening –
>>> and most of the science that is happening is in the psychology of
>>> programming, about which most developers of programming languages know
>>> nothing.
>>
>> If you're hinting that I know nothing about the topic, you're mistaken :-)
>>
>> A fair amount of D's design is based on psychology.
> 
> I'd love to hear more about this sometime.

One fun example is our quest to find the right keyword for read only data. A long list of words were examined, like readonly, invariant, etc. Some had various baggage connotations, some weren't clear what they meant.

We found ourselves constantly saying things like: "readonly means immutable", "invariant means immutable", etc. Finally we got hit with a clue-by-four - everyone understood what "immutable" meant, so why not just use "immutable"?

Pure psychology, and nothing to do with computer science.

---

Another is it is known that people have cognitive problems with negation. It often just does not register in the mind. This is why version statements in D do not have negation. It more or less forces one to think of using positive version identifiers:

    version (hasFeature) { ... }

as opposed to:

    version (!hasFeature) { ... }

or even worse (yes I've seen it):

    version (!doesNotHaveFeature) { ... } // :-(

In order to do negation, one must resort to:

    version (hasFeature) { } else { ... }

Having converted a lot of C code to D and dealing with things like:

    #if !__OSX__
       ... call X ...

having to redesign the case to use positive features:

    version (hasX)
       ... call X ...

makes the code a lot more readable. It's worth it.

The psychological cognitive issues around negation are known, but I rarely see deliberate efforts by programmers to deal with that issue. D kinda forces it, and I get resistance to it, but it is worthwhile to push it because the results are worth it.

On Wednesday, 27 December 2017 at 20:48:12 UTC, Walter Bright wrote:
> On 12/27/2017 8:38 AM, Laeeth Isharc wrote:
>> On Wednesday, 27 December 2017 at 07:44:30 UTC, Walter Bright wrote:

> The psychological cognitive issues around negation are known, but I rarely see deliberate efforts by programmers to deal with that issue. D kinda forces it, and I get resistance to it, but it is worthwhile to push it because the results are worth it.

I nearly always reorganise my code so that my `if` statements are positive precisely because of this. The only times I don't is when the negative branch is a lot shorter, so I "get it out of the way" sooner. Even then I try to rename the boolean value to not require negation.

I had a hard time convincing my colleagues at my previous job that this was an issue. Then again I had a hard time convincing them unit tests were a good idea, so there's that.

Atila

On 12/27/2017 1:00 PM, Atila Neves wrote:
> I nearly always reorganise my code so that my `if` statements are positive precisely because of this. The only times I don't is when the negative branch is a lot shorter, so I "get it out of the way" sooner. Even then I try to rename the boolean value to not require negation.
> 
> I had a hard time convincing my colleagues at my previous job that this was an issue. Then again I had a hard time convincing them unit tests were a good idea, so there's that.

I once talked to a real estate agent who told me his proxy for a well-built house was whether the screw slots on the electrical outlets lined up or not.

On 12/27/2017 8:57 AM, Laeeth Isharc wrote:
> It's much better to have a monopoly of some niche or set of niches and to use energy from success to expand out from there, than to have a small market share of an enormous market.

Back in the 80's, Zortech made a killing because we had the only C++ compiler that would generate 16 bit Windows code.

I found this out by asking the sales guys what feature of ZTC++ was closing the deal - X, Y, Z, all the features I held dear. They'd say nope. Customers wanted to use C++ for Win16, ZTC++ supported that, sold!

I learned a lot from that.