On Monday, 16 October 2017 at 00:25:32 UTC, codephantom wrote:
D's overview page says "It doesn't come with .... an overriding
philosophy."
Is philosophy not important?
I'd like to argue, that the problem of focusing on getting the
job done quickly and reliably, does *not* leave behind
maintainable, easy to understand code, but rather it leads to
unintended outcomes ...
If the philosophy of C, is 'the programmer is in charge', what
might the philosophy of D be?
e.g. Maximum precision in expression, perhaps?
I believe D not having a philosophy was very important when I
ported all my projects from python to D. Let me explain.
I had a very important project that I've been using everyday for
two-three years, written in python, and I grew tired of the
negative effects of interpreted languages. I needed to take a
risk and perform a complete rewrite to counter the issues. My new
language needed to excel in the following categories for the
rewrite to be successful: performance, testing, and learning
curve. The candidates were Rust, Go, Haskell, Swift, and of
course D.
Rust had a difficult learning curve and it was not easy to port
Python code to Rust, therefore that language was ignored. Haskell
stuck to the philosophy of a purely functional language, which
made the learning curve dramatic and I had to ignore this
language. Swift seemed to be focus more on cocoa apps over
command line apps, so I ignored this language as well. This left
me with Go and D, both languages that solved my requirements. Let
me tell you why I choose D.
D gave me the freedom to code the way I wanted to, Go forced me
to think "simply". D gave me every feature possible to solve my
problem, Go took them away. D allowed me to program in a style
that matched the problem at hand, Go forced me to follow only one
style. Are you seeing the pattern? When you religiously follow a
philosophy, you're limited to only solving problems that play
well with that philosophy.
