How do you use D?

[Joakim]

On Wednesday, 3 January 2018 at 11:43:35 UTC, Paulo Pinto wrote:
> On Wednesday, 3 January 2018 at 11:13:04 UTC, Joakim wrote:
>> On Wednesday, 3 January 2018 at 10:29:05 UTC, Ola Fosheim 
>> Grøstad wrote:
>>> On Wednesday, 3 January 2018 at 09:56:48 UTC, Pjotr Prins 
>>> wrote:
>>> [...]
>>
>>> Good programmers aren't stuck on any single language and will 
>>> pick the tool best suited for the job at hand.  Good 
>>> programmers are also good at picking up new languages.
>>
>> And who do you know who does this?  While I myself have 
>> espoused the idea of the best tool for the job in this forum, 
>> realistically, other than a small handful of coders, when does 
>> that ever happen?
>> [...]
>
> Everyone at my employer, a few thousand of them doing 
> enterprise consulting.
>
> We specialize in a few large domains, and tend to jump between 
> them every 6 months or a year, when switching projects.
>
> On my case, full stack development across JVM and .NET 
> languages, with C++ for low level coding.

How many of those few thousand are actually comfortable with C++ 
for low-level coding?  I think you've said before that it's not 
many. So okay, your colleagues switch between Java and C#, which 
is somewhat uncommon as many places are pure C# or Java shops, 
but those are the two most popular enterprise application 
languages, noted for their similarities.

You can hardly use this as an example of having a toolbox of 
languages and picking the best for the job, say Erlang for some 
high-concurrency microservice or ruby for an app you need to get 
up and running quickly.  You're just using two of the most 
popular business languages and deciding which based on what the 
customer wants.

On Wednesday, 3 January 2018 at 14:08:20 UTC, Ola Fosheim Grøstad 
wrote:
> On Wednesday, 3 January 2018 at 11:13:04 UTC, Joakim wrote:
>> Not necessarily, it all depends if thinking you're the best 
>> leads to taking your eye off the ball of improving and 
>> acknowledging your problems, which I see little indication of 
>> here.
>
> Well, if a language is used for a narrow set of application 
> areas then one might be able to have a deep understanding of 
> what the challenges are.
>
> In general I think it is difficult to understand what 
> challenges people have in areas one have little familiarity 
> with. I've seen this time and time again in discussions about 
> memory management.
>
> I think both Rust and D suffers a bit from this.  And likewise, 
> I think C++ designers are making a mistake by presuming that 
> C++ can become a competitive high level language.
>
> So it is a general challenge in language design, I think.

These languages may all have these problems, but I don't see the 
connection to your original point about it not being good to 
think you're the best.

>> And who do you know who does this?  While I myself have 
>> espoused the idea of the best tool for the job in this forum, 
>> realistically, other than a small handful of coders, when does 
>> that ever happen?
>
> I don't know how many…  But if you have a good understanding of 
> a language like Java and C/machine language, and also have the 
> equivalent of a bachelor in comp sci, then I think you should 
> be able to pick up just about any language in relatively short 
> time (except C++ where the know-how is less accessible for 
> various reasons).

More programmers don't have a bachelors in CS than those who do.  
I think you'll find the percentage who regularly use multiple 
languages is fairly low, let alone evaluating each one for each 
job.

> Anyway, it is my impression that many C/C++ programmers also 
> know Python and also have a good understanding of basic 
> functional programming.

So two tools in the toolbox is enough?

>> I recently read some article linked off proggit that stated 
>> the reality much better: programmers learn a language that 
>> suits them, then use it everywhere they can.
>
> Well. Take an iOS programmer. She/he would start out with 
> Objective-C, which requires understanding of C. Then maybe you 
> also need to interface with C++ in order to use some library. 
> Then you switch over to Swift… Then you need to port the app to 
> Android and have to pick up some Java. Then somebody want to 
> turn it into a webapp and you pick up TypeScript… Then someone 
> needs interfacing with C# for a web-service and you pick up a 
> bit of that…
>
> As long as you are interfacing with other systems you often 
> achieve more by learning enough to use something written in 
> another language than by picking a suboptimal solution that use 
> your favourite language.

If you're just stitching together a bunch of libraries written by 
others, sure, you can pick up enough to interface them.  But we 
were talking about switching between significant use of each 
language based on the job, which almost never happens.  Your 
company is much more likely to bring in somebody with Java 
experience to write the Android portion.

> But sure, if I need to hack together something I would usually 
> think about using Python first, mostly because it is so 
> mallable for smaller tasks. Not really because it is my 
> preferred language. I don't really like dynamic typing in 
> principle, but it is productive for smaller tasks and 
> prototyping.

Whatever the reason, everybody has their go-to language that they 
generally stick to.  Very few have a deep toolbox of languages, 
where they just pull out the best one for each job.  It is 
unrealistic to expect the vast majority of programmers to do any 
more than use one language most of the time.

>> Given how much effort it takes to know a language platform 
>> well, not only the language itself but all the libraries and 
>> their bottlenecks, and most programmers' limited motivation to 
>> pick up new tech, that is the only approach that makes sense 
>> for the vast majority.
>
> Well, but libraries and frameworks are unfortunately not 
> permanent. They are shifting relatively fast. Heck, even the 
> Java standard library contains many things that you don't want 
> to use, because there is something better in there.
>
> So if you start on a new project there is often a more 
> productive framework you could go with.

This actually argues for a single language: you're going to spend 
a ton of time tracking all those shifting frameworks so you won't 
have time for a new language too, but at least you won't have to 
learn a new language every time you pick up the new js framework 
of the day.

> And that might require adopting a new language as well.
>
> This is of course good for new languages. If this was not the 
> case then it would be near impossible for new languages to 
> establish themselves.

The ongoing churn may help new languages with new users and 
companies, don't think it helps with users who already know a 
language well.

> But it can also be taken as a sign that we don't have the 
> languages and tooling that enable writing really good timeless 
> libraries and frameworks.

Seems like an oxymoron, tech changes so fast that I don't see how 
anything could be timeless, even if you really mean "will still 
be the same 20 years from now." ;)

> Maybe that will change in the future, I guess we now are 
> reaching a point where neither CPU or memory are the limiting 
> factor for most mundane applications. So maybe that will cause 
> a more stable infrastructure to emerge… but probably not in our 
> lifetime. I think we still have a long way to go in even simple 
> areas such as GUI frameworks.

There's always new stuff other than that, eg more limited mobile 
hardware over the last decade has returned the tech market to 
earlier times, and native languages like Obj-C and Swift have 
benefited.

>> Yes, but if you're only hyped because you were stowed away on 
>> a popular platform, ie javascript in the browser, or are easy 
>> to learn, Go from what I hear, then the technical limitations 
>> of the language put a ceiling on how high you can go.  You'll 
>> get to that ceiling faster, but then you're stuck there.
>
> I perceived that there was a lot of hype around Python 15 years 
> ago or so. Now, universities are replacing Java with Python as 
> the introduction language and Python is also becoming the 
> defacto language for scientific programming. Python is 
> basically getting critical mass and is now managing to take on 
> Matlab and perhaps  to some extent even C++/Fortran.

Python has done well in those niches, but when is the last time 
you saw a popular GUI app written in Python?  That is the largest 
segment of the market, and Python has basically no uptake there.  
Even Java got nowhere in the consumer GUI market, other than a 
few p2p apps like Vuze and the now-defunct Limewire, largely for 
piracy.

> There is a loooong road for languages like Rust, D and Julia… 
> All those scientific simulation frameworks creates are rather 
> heavy critical mass. That is very difficult to move around 
> (Matlab was for a long time dominant).

While that market may be important to you, it is a small segment 
of the programming market.  It's nice that D libraries like Mir 
are targeting it, but it's not going to move the needle much.

>> And who's to say D doesn't have critical mass?  I'd say 
>> 100-200k users (my math based on the chart below: 2k 
>> downloads/day of dmd X 60 days between major versions + 
>> ldc/gdc and external downloads) is a significant market:
>>
>> http://erdani.com/d/downloads.daily.png
>
> I don't know what to make out of the download metric. It would 
> be easier to grasp if it was broken down into regional 
> downloads and if it isn't already, filtered by unique IPs.

I believe it is filtered for repeated downloads, but we don't 
know exactly how.

>> It's not hyped or popular, but you can leverage that base to 
>> get bigger, particularly since you didn't sell out and 
>> specialize to get that base in the first place.
>
> Well, but nobody picks a language because it is a good language 
> for building libraries. They might avoid a language if it is 
> bad at that, but for a single application you often don't need 
> generic programming.

You don't pick a language for that, you pick it because it has 
all these great libraries that make building your app faster.  
You may not even know that's because of generic programming, you 
just like all the great libraries.  IOW, you may think you don't 
need generic programming, but the libraries you do need do need 
it.

> When focusing on a niche you have an easier sell for the 
> specifics of a project. Being a bit better than Rust at this, 
> Go and that and C++ an this and that, isn't given as much 
> weight as "hands down most productive solution for Y". And 
> being the most productive goes beyond language and even 
> libraries, it also includes knowhow and online tutorials for 
> that narrow area.

I'd argue it's historically actually been the opposite: just pick 
a popular language and go with it, without bothering to figure 
out if there's some niche language better suited for Y.  With the 
fragmentation in languages over the last decade and a half, 
that's been changing, partly because of how much easier it is to 
get the word out about these less-popular languages on the 
internet now.

However, there's always going to be space for a few 
general-purpose languages to complement the many single-purpose 
languages.  D's aiming for the former, not the latter.

I understand you think the former are on the way out but many of 
us disagree, for the reasons laid out above.