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

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
>

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

"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.

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

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

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

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).

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.

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.