On Wednesday, 3 November 2021 at 06:08:57 UTC, harakim wrote:

Sigh. If you think that being a developer with roughly normal feelings makes your experience to qualify as research results, I don't even know where to begin. You're underestimating the problems by an incredible factor. You have a lot, lot to learn about doing research.

On Wednesday, 3 November 2021 at 05:20:11 UTC, Ola Fosheim Grøstad wrote:

Qualitative research is okay. But it has to be based on much more than what people say on the forum / Reddit / Hacker news. Following and analyzing the development on GitHub and alternatives would be a start, but even that misses closed-source projects and the underlying reasons on why people come and go. So ideally we want something else too, say interviews.

The research should consider a spectrum of possibilities. Each theory the research considers unlikely in the conclusion, it must provide evidence against. It is not enough to provide evidence for the possibility considered likely.

Perhaps you have done something like that already. But if you can not or will not show it, we others have no way of telling your theory from yet another forum ramble.

Note that I'm not taking this stance for all forum discussions. When discussing DIPs for example, you can provide examples everyone can verify (or debunk). But if you're saying that a stronger vision will/would have attracted more people, only research can really tell.

On Wednesday, 3 November 2021 at 11:03:35 UTC, Dukc wrote:

Interviews would be good, but I think you are putting too much faith in research practices. Of the papers I've read, in 90% of the cases I would have objections to their conclusions based on the methodology (for both qualitative and quantitative methods).

If you don't want to participate in a line of reasoning, of course, you don't have to. In general, researchers tend to be very open to explore ideas in the way we do in this thread, so I don't quite share your objection to ranting. When you explore ideas through a line of reasoning then other people can choose to dig into it, find new angles and ideas following from it, or they can ignore it.

But qualitiative analysis is an exploration. You don't aim to grade impact in a predictive manner, you try to unfold many different aspects of a process so that you can form a model of what might influence it. Also bringing nuances into an analysis is a very important aspect where quantitative methods shine. Then you also have interpretative research applying models of power etc to situations.

The world is not black and white. You don't have to wait for someone to do formal data collection to explore the nuances of the situation.

On Tuesday, 2 November 2021 at 19:42:45 UTC, Imperatorn wrote:

We seem to be afraid of doing anything that doesn't work in >>insert fringe edge case the language designers care about<<

Yeah, was a bit vague. What I was getting at is some D libraries have a requirement of some C library, but expect you to build said C library yourself, which sometimes is very straightforward, but is sometimes a nightmare.

And then sometimes you have to go to a C library since D doesn't have a (functioning) package you need, so then you have to write C-style code alongside your normal D code.

On Wednesday, 3 November 2021 at 12:00:48 UTC, Ola Fosheim Grøstad wrote:

You're assuming the truth is such you can infer it from what you see without going out to collect more data, and trust your analysis. There is no reason to assume so. We forum participants are likely to be a highly self-selected group.

I do understand that you have programming experience from other places too, but realistically you're definitely not such a polyglot that you can see all the bubbles from the outside. Think Walter. He has seen pretty much everything, yet all of us can see blind spots in his thinking fairly often. You cannot expect yourself to do much better than Walter no matter how experienced you are.

On Wednesday, 3 November 2021 at 12:52:10 UTC, Dukc wrote:

I am not assuming, I am presenting a viewpoint with arguments. Also don't assume that research is about conveying truth. It is about providing perspectives, models and ideally a transparent exposition. In reality you can always dismiss research on complex systems, by just pointing out that the context is different, the sample is biased, the analysis is biased, that they only looked for X and didn't look for Y, and that the results cannot be used for prediction.

But that does not mean that the perspectives and models are useless.

I don't know how to respond to this. Let us keep Walter out of the analysis.

On Tuesday, 2 November 2021 at 18:57:32 UTC, Paulo Pinto wrote:

On day one of their "introduction" (these languages were started way before their public release) Rust, Go and Swift had a marketing narrative that was both simple and then advertised to the public, with money.

These narrative play on people aspirations, by telling what they want to hear about themselves.

Go: "You're going to Google scale."

Rust: "We nailed security. You care about security, right? Also you're going to be one of those badass system programmers where things go fast."

Swift: "Well you have no choice. This is the future (if you want to sell something to Apple users)."

I think they not quite subtly played on FOMO.
I think D also has a narrative actually:

D: "You too can be financially independent by crushing the competition with D and hard work. More power than C++."

hence "Do It In D".

The problem is that the (Go/Rust/Swift) stories speaks to more people, like people in managerial positions. D's underhanded motto - and that's just an opinion - is fundamentally an appeal for way fewer people; I'd like to elaborate more but probably I'm just speculating without substance.

I don't think features or bugs ever entered the picture! Or only to support or contradict the main narrative.

On Wednesday, 3 November 2021 at 13:25:18 UTC, Guillaume Piolat wrote:

Does FOMO mean "fear of missing out"? Maybe, but I think they also played up to a dissatisfaction with system level programming being tedious, and alluding to the power of system level programming to programmers that had not gone there before. (D does too.) Go later distanced themselves from system level programming, when people saw that it was not suitable for that, and rightfully felt that they were mislead, but maybe they still benefited in terms of hype from the controversy?

D did receive quite a bit of hype for being a possible successor to C++ on Slashdot around 2006/2007 or so (at that point in time /. was more inclined to publish stories about new exciting tech). Basically, D was projected as become the language that would remove the complexities of C++ and make you more productive. I doubt I would have looked at D if the connection to C++ wasn't used as a "marketing trajectory".

At launch or now? Initially I think developers want to taste the latest and greatest and get a glimpse of the future. So when Apple or Google release a new language many will study it. I think many with an academic background got excited about Rust, just on paper, so the setup was blogger friendly.

Now, I think it is by and large critical mass. Go has a solid runtime for cloud micro services. Swift is a platform. Rust, a good choice when C++ is too low level and Go is too high.

On Wednesday, 3 November 2021 at 14:02:52 UTC, Ola Fosheim Grøstad wrote:

What I meant is that posting of the spec on Slashdot in 2001 wasn't a carefully executed software release you could have for... consumer applications and new languages from big companies.

Absolutely.
For me it was playing Kenta Cho games and noticing they were all written in D, without source available, and the sheer amount of innovation and grit that Kenta would display through his games. I did fall for D later having to use C++ at work, because it instantly felt wrong after a long exposure to the Wirth family of languages. So yes exposure to C++ highlight the value of D more I guess, so you can get the issue of intersecting audiences.

On Wednesday, 3 November 2021 at 13:25:18 UTC, Guillaume Piolat wrote:

D's user must be senior technicians, ordinary it people don't care it. And they are more willing to take risks to start a business.
More power than C++ and Money, More independent, freedom, risks.
For first class talent.