www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Why I like D

reply bearophile <bearophileHUGS lycos.com> writes:
Few moths ago someone here has implicitaly asked why I like D, now I can
answer. Feel free to skip this boring wall of text.

I don't like the syntax and rules of C++, to me they look ugly, confusing and
too much complex, and when I can I avoid this language. It makes me waste too
much time, and I don't like to learn all its special cases.

I like Python because it's small enough to fit into my limited brain (few parts
of D seem to not fit in my brain well, and I may suggest to improve them to
make them more intuitive and simpler), because it's designed for the programmer
and not for the CPU, because it helps me avoid many kinds of bugs, because its
syntax is clean, readable and easy to remember. It also has tons of std lib and
third-part modules, that allow me to plot things, process images and sounds,
create GUIs, and lots of other things.

But for some of my purposes Python is too much slow, and I have not appreciated
all the tons of solutions used by Python programmers to solve this problem. I
have even given a big hand to help the development of a Python compiler
(ShedSkin) but I now think it's a failed experiment. The only solution I like
to use is Psyco, but often it doesn't lead to fast enough programs.

In some of my programs I need more than just speed: my problem may require lot
of memory (and even if it's not a lot of memory, compacting the memory usage
usually leads to better performance), and genrally I just want the freedom of
managing memory as I like, so I need something like structs, unions, pointets
and all that "unsafe" stuff. The D GC allocates blocks of memory as powers of 2
(under a certain size) and I don't like that much, but there's the
std.c.stdlib.malloc too anyway, for special situations.

Speed coming to being closer to the metal and freedom of memory usage allow me
to solve problems that you can't solve in a acceptable time with Python. For a
silly recent example, it has allowed me to compute the next number of this
sequence, with a program 40 times faster than the original Python one:
http://www.research.att.com/~njas/sequences/A119770
Of course you can wait a day to receive the answer from the Python program, but
if the problem space gets ten times bigger I can still use the D program...
Beside this one, I can offer several others less silly examples where the speed
of the D program was essential, or where for example I have used almost 2 GB of
RAM in an effective way (where using a dynamic language was hopeless), in
bioinformatics problems, graph-related problems, etc.

Of course I can use Delphi, C, C++ or CommonLisp to write such programs, but I
have seen that I am much slower in writing C code, compared to D code, even if
I am using C for much more time. D helps me avoid problems and bugs, and just
the built-in arrays are a huge time saver, expecially when you want to manage
2D arrays (so D allows me to write low-level code only where I want, to speed
up hotspots and not to write all the program in low-level style as C programs
generally require). Delphi language is much less modern and offers me less nice
things.

Using my dlibs I need only a short time and almost no pain to translate Python
code to D, or to write high-level D code in the first place (translating it to
C/C++ is surely much more painful, even if someone write something as my libs
for C++), but with D I can also write in a style very close to C, this is
useful to translate slowly higher level code to actual C programs (so I use D
as an intermediate language progressively closer to C or even to asm). I can
also inline asm code, and learn more assembly, more things about the CPU and
write fast SSE code.

So I like D because it's a multi-level language (vaguely as C++), because it
helps me avoid lot of bugs I put into C programs, while being still simple
enough for my limited mind to learn and manage, unlike C++.

I have also appreciatd D because it has given me the chance to re-learn several
things of computer science and how a low-level language works. There are
several things I don't know still that are often discussed in this newsgroup,
so I have more to learn.

Using D sometimes gives me the same fun people receive from solving puzzles:
the complex things I have used for example to create the Record struct of my
dlibs (that mimics a little the tuples of Python) has required me about one
year of work, and it was better than a complex puzzle. Now for example such
Record support opCmp and hashing, even if they recursively contain vanilla
structs :-)

Haskell language will surely teach me several other things that D (and other
languages I know) doesn't know about. But even very common languages like Java
offer a lot of things to learn that are not much present in the D programming.

D currently has tons of problems and weak spots, first of all the way it is
developed, and I really hope to see it fix some of such problems, but for my
purposes it's better than most of the alternatives.

Bye,
bearophile
Dec 04 2008
parent reply "Bill Baxter" <wbaxter gmail.com> writes:
Sounds pretty close to my thoughts on the subject.

A couple of years ago I decided that I was really tired of fighting
with with C++ (mostly the memory micro-management, the horrible
template mess, and totally unreadable code in standard libs like Boost
and STL).  So I decided to find something easier and more fun to use.
I decided that I would go with 1 dynamic language and 1 static
compiled language.   After looking around I decided on Python for the
dynamic language, (primarily because of the active NumPy/SciPy
community), and for the static language I chose OCaml because it
sounded like a nice hybrid of functional with OOP, and appeared to be
used by various people who care about having their numerical code run
fast.

But then I sat down to try to figure out how to write a simple OpenGL
program in OCaml.  Hmm.  Couldn't find anything about it.  From a
quick google just now, I see someone made some GL bindings late in
2007, but that was too late for me.  Anyway it wasn't just the lack of
GL bindings.  It was sitting down and realizing that with OCaml I was
basically going to have to re-learn how to do everything I already
knew how to do, but using Monads or whatever.

Python didn't put any such roadblocks in my way so I got started using
it right away with no problems.  No problems, that is, until I started
trying to write some very loop-intensive mesh processing code.  And it
was just soooooo slooooooow.  And I began spending lots of my time
trying to figure out how to turn simple nested loops into one-line
vector expressions just so that Numpy would run them at reasonable
speed.  And I also got increasingly annoyed by the silly runtime
errors that any decent compiler would tell me about.    I got a Python
IDE which I liked, but I realized that the startup time for running
python programs in that IDE was about as long as compile times for
equivalently sized programs in C++, so where's this supposed advantage
from not having to compile?

The same time I had been eyeing D, and occasionally checking out the
webnews but I had the concept that it was hard to integrate with other
code because I would need special versions of all my libraries (DMD
COFF libs vs the MS libs I have lying around already).  That put me
off a bit.   But as I got into Python more I started learning how to
write my own native Python modules, and started getting the hang of
it.  At some point I realized, hey, getting my C code to work with D
is kind of like writing a native Python module, but a *whole lot
easier*!  All I have to do is re-write function signatures, instead of
doing a bunch of funky PyTuple_FromArgs() PyIncRef() nonsense!  Funny
how perspective works.  From a C++ coders perspective the hoops D was
going to make me go through looked very annoying, but with Python
goggles on, talking to C code from D looks like a walk in the park.

So I decided to give D a serious test drive.   And it's turned out
very well.  D is a lot of fun to develop with.

Even when I think about the downsides of D -- having to write or port
a lot of my own libraries, working around compiler bugs, not having a
super-duper GUI debugger (and when I started no real debugger at all)
-- all these things are much less annoying than trying to debug some
intricate memory allocation issue in C++ or trying to figure out why
some complex template lib like boost::serialize is not working.  So
maybe overall I don't develop much faster, but I sure have a lot more
fun doing it.  Especially the first one -- having to write or port
your own libs -- it may be a lot of extra work you wouldn't have to do
in C++, but it's kinda fun, and when you're done you know your lib
inside and out and know you can fix any problem that arises.  Heck,
even with C++ many developers will rewrite even when they could reuse
just because they prefer that level of ownership and total control.

Now I just wish the BigMegaCorps of the world would take notice and
write us some nice VisualStudio-caliber integrated gui IDE/debuggers.

--bb

On Fri, Dec 5, 2008 at 4:20 AM, bearophile <bearophileHUGS lycos.com> wrote:

 Few moths ago someone here has implicitaly asked why I like D, now I can
answer. Feel free to skip this boring wall of text.

 I don't like the syntax and rules of C++, to me they look ugly, confusing and
too much complex, and when I can I avoid this language. It makes me waste too
much time, and I don't like to learn all its special cases.

 I like Python because it's small enough to fit into my limited brain (few
parts of D seem to not fit in my brain well, and I may suggest to improve them
to make them more intuitive and simpler), because it's designed for the
programmer and not for the CPU, because it helps me avoid many kinds of bugs,
because its syntax is clean, readable and easy to remember. It also has tons of
std lib and third-part modules, that allow me to plot things, process images
and sounds, create GUIs, and lots of other things.

 But for some of my purposes Python is too much slow, and I have not
appreciated all the tons of solutions used by Python programmers to solve this
problem. I have even given a big hand to help the development of a Python
compiler (ShedSkin) but I now think it's a failed experiment. The only solution
I like to use is Psyco, but often it doesn't lead to fast enough programs.

 In some of my programs I need more than just speed: my problem may require lot
of memory (and even if it's not a lot of memory, compacting the memory usage
usually leads to better performance), and genrally I just want the freedom of
managing memory as I like, so I need something like structs, unions, pointets
and all that "unsafe" stuff. The D GC allocates blocks of memory as powers of 2
(under a certain size) and I don't like that much, but there's the
std.c.stdlib.malloc too anyway, for special situations.

 Speed coming to being closer to the metal and freedom of memory usage allow me
to solve problems that you can't solve in a acceptable time with Python. For a
silly recent example, it has allowed me to compute the next number of this
sequence, with a program 40 times faster than the original Python one:
 http://www.research.att.com/~njas/sequences/A119770
 Of course you can wait a day to receive the answer from the Python program,
but if the problem space gets ten times bigger I can still use the D program...
 Beside this one, I can offer several others less silly examples where the
speed of the D program was essential, or where for example I have used almost 2
GB of RAM in an effective way (where using a dynamic language was hopeless), in
bioinformatics problems, graph-related problems, etc.

 Of course I can use Delphi, C, C++ or CommonLisp to write such programs, but I
have seen that I am much slower in writing C code, compared to D code, even if
I am using C for much more time. D helps me avoid problems and bugs, and just
the built-in arrays are a huge time saver, expecially when you want to manage
2D arrays (so D allows me to write low-level code only where I want, to speed
up hotspots and not to write all the program in low-level style as C programs
generally require). Delphi language is much less modern and offers me less nice
things.

 Using my dlibs I need only a short time and almost no pain to translate Python
code to D, or to write high-level D code in the first place (translating it to
C/C++ is surely much more painful, even if someone write something as my libs
for C++), but with D I can also write in a style very close to C, this is
useful to translate slowly higher level code to actual C programs (so I use D
as an intermediate language progressively closer to C or even to asm). I can
also inline asm code, and learn more assembly, more things about the CPU and
write fast SSE code.

 So I like D because it's a multi-level language (vaguely as C++), because it
helps me avoid lot of bugs I put into C programs, while being still simple
enough for my limited mind to learn and manage, unlike C++.

 I have also appreciatd D because it has given me the chance to re-learn
several things of computer science and how a low-level language works. There
are several things I don't know still that are often discussed in this
newsgroup, so I have more to learn.

 Using D sometimes gives me the same fun people receive from solving puzzles:
the complex things I have used for example to create the Record struct of my
dlibs (that mimics a little the tuples of Python) has required me about one
year of work, and it was better than a complex puzzle. Now for example such
Record support opCmp and hashing, even if they recursively contain vanilla
structs :-)

 Haskell language will surely teach me several other things that D (and other
languages I know) doesn't know about. But even very common languages like Java
offer a lot of things to learn that are not much present in the D programming.

 D currently has tons of problems and weak spots, first of all the way it is
developed, and I really hope to see it fix some of such problems, but for my
purposes it's better than most of the alternatives.

 Bye,
 bearophile
Dec 04 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:
Bill Baxter:


It was sitting down and realizing that with OCaml I was basically going to have
to re-learn how to do everything I already knew how to do, but using Monads or
whatever.<


A little learning pain may be useful to grow. So learning some functional
programming may be positive.
It may even become useful for D :-)



And I also got increasingly annoyed by the silly runtime errors that any decent
compiler would tell me about.<


Generally I don't have such problems, but maybe my style of coding is quite
"careful" anyway.

Bye,
bearophile
Dec 04 2008
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:gh9gqv$25lf$1 digitalmars.com...

 Bill Baxter:

And I also got increasingly annoyed by the silly runtime errors that any 
decent compiler would tell me about.<


 Generally I don't have such problems, but maybe my style of coding is 
 quite "careful" anyway.


That's the reason I refuse to use dynamic languages and indentation-syntax 
languages whenever I have a choice. They're nothing but a giant step 
backwards, constantly replacing the most basic and standard compiler 
diagnostics with the world's most unnecessary runtime atrocities.

D is great because it proves to the world (or at least the few non-scripter 
programmers still out there) that good things like clean syntax, 
safety/reliability, functional-features-in-an-imperative-language, 
reflection, high productivity, etc are absolutely not things that in any way 
necessitate a dynamic language or a VM. I think there are *way* too many 
people out there who associate "static typing", "natively-compiled", and 
"general purpose" directly with "C++", and that's an absolute shame because 
C++ is probably one of the worst examples of those things, especially in the 
presence of D.
Dec 04 2008
next sibling parent Graham St Jack <Graham.StJack internode.on.net> writes:
On Thu, 04 Dec 2008 17:44:34 -0500, Nick Sabalausky wrote:


 "bearophile" <bearophileHUGS lycos.com> wrote in message
 news:gh9gqv$25lf$1 digitalmars.com...

 Bill Baxter:

And I also got increasingly annoyed by the silly runtime errors that
any decent compiler would tell me about.<


 Generally I don't have such problems, but maybe my style of coding is
 quite "careful" anyway.


 That's the reason I refuse to use dynamic languages and
 indentation-syntax languages whenever I have a choice. They're nothing
 but a giant step backwards, constantly replacing the most basic and
 standard compiler diagnostics with the world's most unnecessary runtime
 atrocities.
 
 D is great because it proves to the world (or at least the few
 non-scripter programmers still out there) that good things like clean
 syntax, safety/reliability,
 functional-features-in-an-imperative-language, reflection, high
 productivity, etc are absolutely not things that in any way necessitate
 a dynamic language or a VM. I think there are *way* too many people out
 there who associate "static typing", "natively-compiled", and "general
 purpose" directly with "C++", and that's an absolute shame because C++
 is probably one of the worst examples of those things, especially in the
 presence of D.


I agree. D combines the best of both worlds, and I really can't do 
without lots of compile-time help from the compiler.

For me, D code looks good on the page, is easy to understand, and is FAR 
quicker to develop in and to maintain than the alternatives (I am forced 
to use C++ in my day job).
Dec 04 2008
prev sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Nick Sabalausky Wrote:

 That's the reason I refuse to use dynamic languages and indentation-syntax 
 languages whenever I have a choice. They're nothing but a giant step 
 backwards, constantly replacing the most basic and standard compiler 
 diagnostics with the world's most unnecessary runtime atrocities.


Confusing two things there. Haskell is an indentation-syntax language, but not
dynamic. The compiler catches quite a bit.
Dec 04 2008
parent "Nick Sabalausky" <a a.a> writes:
"Robert Fraser" <fraserofthenight gmail.com> wrote in message 
news:ghabu5$1v4$1 digitalmars.com...

 Nick Sabalausky Wrote:

 That's the reason I refuse to use dynamic languages and 
 indentation-syntax
 languages whenever I have a choice. They're nothing but a giant step
 backwards, constantly replacing the most basic and standard compiler
 diagnostics with the world's most unnecessary runtime atrocities.


 Confusing two things there. Haskell is an indentation-syntax language, but 
 not dynamic. The compiler catches quite a bit.


No, I'm keeping a clear, deliberate separation between dynamic-typing and 
indentation-syntax here. For all I know, indentation-syntax might be less 
problematic in a functional language like Haskell, but besides Python, I've 
used another indentiation-syntax language, SPIN (not dynamic typed), and 
even in that I found the indentation stuff to be never helpful, but 
sometimes problematic (it misses scope-related bugs that never would have 
occurred in the first place in any non-indentation language). If Python 
really wants to put an end to improperly indented source files, it should 
error out when indentation doesn't match non-whitespace block markers 
instead of running around assuming everything to be written as intended.
Dec 05 2008
prev sibling parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Fri, Dec 5, 2008 at 6:07 AM, bearophile <bearophileHUGS lycos.com> wrote:

 Bill Baxter:


It was sitting down and realizing that with OCaml I was basically going to have
to re-learn how to do everything I already knew how to do, but using Monads or
whatever.<


 A little learning pain may be useful to grow. So learning some functional
programming may be positive.
 It may even become useful for D :-)


Agreed.  I knew some ML from grad school, so it wasn't totally new to
me.  But dabbling a bit in a different language is a big step from
diving in head first and making that your primary development
language.


And I also got increasingly annoyed by the silly runtime errors that any decent
compiler would tell me about.<


 Generally I don't have such problems, but maybe my style of coding is quite
"careful" anyway.


You never mistype the name of a variable?

--bb
Dec 04 2008
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Bill Baxter:

 You never mistype the name of a variable?


Probably I do such mistakes often or very often, but I test every little piece
of code I write, so such bugs are fixed seconds or minutes after I have put
them in, so even not using an IDE I have never felt it as problem :-)
There are far worse bugs that no (normal) type system can catch, that need what
you have between the ears to be fixed :-)

Bye,
bearophile
Dec 04 2008
parent reply Don <nospam nospam.com> writes:
bearophile wrote:

 Bill Baxter:

 You never mistype the name of a variable?


 
 Probably I do such mistakes often or very often, but I test every little piece
of code I write, so such bugs are fixed seconds or minutes after I have put
them in, so even not using an IDE I have never felt it as problem :-)
 There are far worse bugs that no (normal) type system can catch, that need
what you have between the ears to be fixed :-)


I think for dynamic languages, test-driven development is mandatory. But 
you have to write zillions of tests because the compiler accepts all 
kinds of garbage. Compile-driven development is practically impossible 
in a language like PHP.
I like that D gives us the best of both worlds -- you only have to write 
tests to find the 'requires brain' bugs.
Dec 05 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:
Don:

 I think for dynamic languages, test-driven development is mandatory.


I generally write tests after the code in all languages I use :-) Maybe I'll
learn to use TDD in the future, who knows.



 But you have to write zillions of tests because the compiler accepts all 
 kinds of garbage. [...]
 I like that D gives us the best of both worlds -- you only have to write 
 tests to find the 'requires brain' bugs.


Unfortunately in reality the situation is a little different, and you end
writing many tests in D too (take a look at my dlibs, there are more tests than
code). One of the problems is that the tests you have to write "because the
compiler accepts all kinds of garbage" aren't that many, and they are generally
easy&quick to write and think about. Most of the programming & testing time is
used elsewhere. But the dynamic languages allow you to save time in other ways.
So for me the end result is that when programs aren't too much complex, I write
correct Python code faster than correct D code (this includes testing time
too). While when algorithms and ideas are complex, I take about the same time
in both languages, because there are far more time-consuming things and details
to think about.

I think in 5-10 year we'll look at the static/dynamic typing Wars like today we
look at the C - Pascal Wars: as a thing of the past, as a storm in a bottle.
Because probably most language will have a mix of both, with pluggable type
systems too (two first examples that already exist: Python3 has optional

now ways to allow duck typing).

Bye,
bearophile
Dec 05 2008
parent reply "Nick Sabalausky" <a a.a> writes:
"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:ghb36o$10s1$1 digitalmars.com...

 But the dynamic languages allow you to save time in other ways.


I'd argue that most of those time-saving things are things that have 
absolutely nothing to do with dynamic typing and are perfectly possible with 
static typing. For example, things such as 
function-literals/closures/delegates (with clean syntax), reflection, having 
lots of large helpful libs, and being interpreted or JIT compiled are all 
associated with Python's (and Ruby's) productivity benefits, but none of 
those things even remotely necessitate dynamic typing.
Dec 05 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:
Nick Sabalausky:

 bearophile:

 But the dynamic languages allow you to save time in other ways.


 
 I'd argue that most of those time-saving things are things that have 
 absolutely nothing to do with dynamic typing and are perfectly possible with 
 static typing.


I mostly agree, what I wanted to write is "But Python allows me to save time in
other ways".
There isn't a single cause of my speed of writing correct programs in Python,
and probably nearly all of such causes can be reproduced in static languages

sometimes duck typing may help reduce the 'pressure' coming from a rigid typing
system. A flexible type system like Haskell one may not require this). Maybe
someday someone will create such ensemble of good qualities (often coming from
the standard library, the good choice of names in various things, keeping
simple things simple, from things like the list comprehension syntax, etc).

Bye,
bearophile
Dec 05 2008
parent "Nick Sabalausky" <a a.a> writes:
"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:ghbiuu$a81$1 digitalmars.com...

 Nick Sabalausky:

 bearophile:

 But the dynamic languages allow you to save time in other ways.


 I'd argue that most of those time-saving things are things that have
 absolutely nothing to do with dynamic typing and are perfectly possible 
 with
 static typing.


 I mostly agree, what I wanted to write is "But Python allows me to save 
 time in other ways".

 reduce the 'pressure' coming from a rigid typing system...


I'd agree that optional dynamic typing can, on occasion, be a small time 
saver (Though I can personally live without it), but I still find duck 
typing to be a bit unsettling. Though I admit, the C++/D style of template 
functions does resemble duck typing in a certain way (unless you make heavy 
use of template contraints). I guess that makes we wonder if there might be 


contraints).
Dec 05 2008
prev sibling parent Derek Parnell <derek psych.ward> writes:
On Fri, 5 Dec 2008 07:45:27 +0900, Bill Baxter wrote:


 On Fri, Dec 5, 2008 at 6:07 AM, bearophile <bearophileHUGS lycos.com> wrote:



 Generally I don't have such problems, but maybe my style of coding is quite
"careful" anyway.




 

 You never mistype the name of a variable?


"careful" != "perfect"

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
Dec 04 2008