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
