Dicebot on leaving D: It is anarchy driven development in all its glory.

[Chris]

On Wednesday, 29 August 2018 at 23:47:11 UTC, Laeeth Isharc wrote:
> On Tuesday, 28 August 2018 at 08:51:27 UTC, Chris wrote:

>
> Julia is great.  I don't see it as a competitor to D but for us 
> one way researchers might access libraries written in D.  One 
> could do quite a lot in it, but I don't much fancy embedding 
> Julia in Excel for example, though you could.  Or doing DevOps 
> in Julia.  Perhaps more of a Matlab substitute.
>
> Look around and you can find people grumpy about any language 
> that's used.
> http://www.zverovich.net/2016/05/13/giving-up-on-julia.html
>
> Languages really aren't in a battle to the death with each 
> other.
>  I find this zero-sum mindset quite peculiar.

I'm old enough to a) not become enthusiastic about a language and 
b) know that you can find fault with any language. It's not about 
"life or death". D was promising and I liked it and it did things 
for me no other language could do for me - back in the day. 
Nowadays many languages have similar features, especially the 
useful ones that have proven to be, well, useful and not the 
latest fad. But D has some major issues that have become clear to 
me after using it for quite a while:

1. unsolved issues like autodecode that nobody seems to care about
2. obvious facepalm moments all over the place (see 1.)
3. moving the goal posts all the time and forcing you into a new 
paradigm every 1 1/2 years (first it was "ranges", then 
"templates" and now it's "functional", wait OOP will come back 
one day). Yeah, a language that doesn't come with a paradigm or 
ideology, no, a language that only nudges you into a certain 
direction and makes your code look old and just soooo "not 
modern" according to the latest CS fashion of the day. "Why do 
you complain? If you think C++ (as the D leadership did for a 
long time), of course your code will break, you knob! If it 
breaks it's for your own good (for now)."
4. nitpicking over details of half baked features that shouldn't 
be there in the first place, but hey! let's break valid existing 
code to fix them - or not - or, what about @volatileSafeUB (it's 
sooo not C++)? Yeah, sounds great. We'll just have to issue a 
compiler message "error: cannot assign `size_t` to `size_t`"
5. complete and utter negligence of developer reality (ARM, 
Android, iOS, tools etc.). It's all left to spare time 
enthusiasts - and their code will break in 4 weeks too. Just you 
wait and see
6. the leadership doesn't address the issues and gives evasive 
answers as in "Programmers who..." or on hindsight you're always 
wiser, other engineers have made mistakes too
7. I've seen it all before, many times, and it's a sign of a 
sinking ship, rearranging the deck chairs on the Titanic
8. what a pity
9. I hope D will be great again