Hi there. I am mesmerized by D and I would love to start using it to really learn programming. I've tried it a year ago but failed miserably and went back to C#. The problem I have is that I've been using C# and I feel it left me crippled. I don't understand a lot of the 'mechanical stuff', like how the hell am I supposed to use something I need to build from source, linking to libraries, debugging, etc. C# did a lot of this for me and so I've never learned.

So, after failing to use D for the first time, I decided that it would probably be best to start learning C++ and then, when I have solid understanding of things like these, transition to D. I have the advantage of a friend who lent me /C++ Primer, 5th Edition/ that also covers C++11.

My question is, do you recommend this approach? I am not only talking about learning the syntax - I consider that to be relatively easy. But I want to create meaningful programs and I've always bombed this in C#. I never really knew how to implement things and even though I tried my best to use the SOLID approach, I failed. I am hoping that if I learn C++, I can make use of some other books that discuss program design that I could learn.

Sorry for the longwinded post, but I am kind of desperate at this point.. it's really frustrating to suck at representing ideas in a programming language.

Thanks for any responses

Daemon:

> Thanks for any responses

Let's see. Your post is not longwinded. You don't need to learn C++ to learn D.
On the other hand C++ has more books and free documentation around. But I think learning C++ is harder than D, because D is meant to be cleaned up compared to C++.
Today if you know C++ you are able to use that knowledge in jobs, while D is quite less requested.
C# is a fine multi-paradigm language for several purposes, and you can use it to learn almost anything in programming, even a bit of functional programming, dynamic programming, etc.

Representing ideas in a programming language is hard for most people, it's the human brain that shows its limits at managing that level of complexity. If you think you have problems in 'representing ideas in a programming' then maybe D is not going to help you much more than C#. You need exercises, done in a smart way, to do practice, to have one or more mentors to copy from, lot of time, good books, and so on. To do all this D is not better than C# (probably it's worse, because C# is widespread, has books and courses, there is plenty of software and projects around to contribute to or work for, has better tooling, and so on, so it's easer to exercise with).

Welcome to D again,
bearophile

On 06/06/2013 01:50 PM, Daemon wrote:

> I am mesmerized by D and I would love to start using it to really learn
> programming.

I agree with bearophile. I think D is easier to learn than C++.

> I decided that it would probably be best to start learning C++ and then,
> when I have solid understanding of things like these, transition to D.

Every language has its own idioms, ways of thinking, peculiarities, etc. When you switch languages sometimes you have to unlearn those as well.

> it's really frustrating to suck at representing ideas in a programming
> language.

Programming is still a very difficult task. As you have discovered, even the programming language itself, the most essential tool, takes years to master. Then there are well-known gotchas that you must learn to protect yourself from; some of the basic concepts of programming are extremely difficult to grasp; etc.

Having said all of that, here is my plug:

  http://ddili.org/ders/d.en/

That is a book trying to teach programming in D. Since it was up a year ago, you must have already seen it. If you haven't, I would be happy to hear about criticisms, improvement recommendations, etc.

Ali

On Thu, Jun 06, 2013 at 10:50:05PM +0200, Daemon wrote:
> Hi there. I am mesmerized by D and I would love to start using it to really learn programming. I've tried it a year ago but failed miserably and went back to C#. The problem I have is that I've been using C# and I feel it left me crippled. I don't understand a lot of the 'mechanical stuff', like how the hell am I supposed to use something I need to build from source, linking to libraries, debugging, etc. C# did a lot of this for me and so I've never learned.
> 
> So, after failing to use D for the first time, I decided that it would probably be best to start learning C++ and then, when I have solid understanding of things like these, transition to D. I have the advantage of a friend who lent me /C++ Primer, 5th Edition/ that also covers C++11.

If you're going to learn D, I highly recommend following a book that explains D concepts. Don't pick up bad C++ habits and apply them to D: that will only produce poor D code.  For starters, I recommend this excellent online book (free!) that teaches programming basics using D:

	http://ddili.org/ders/d.en/index.html

Not all of the chapters have been translated from Turkish yet, but the stuff that's already there should be enough to get you started.

And if at all possible, I highly recommend getting a copy of Andrei Alexandrescu's "The D Programming Language" (TDPL). Another classic.


> My question is, do you recommend this approach? I am not only talking about learning the syntax - I consider that to be relatively easy. But I want to create meaningful programs and I've always bombed this in C#. I never really knew how to implement things and even though I tried my best to use the SOLID approach, I failed. I am hoping that if I learn C++, I can make use of some other books that discuss program design that I could learn.
[...]

I don't recommend learning C++ first. Just start with D. The way to improve your coding skills is just to write lots and lots of code. The more you write, the better you'll get at it.

After you've gained enough experience, if you want to learn *real* programming, and you're willing to learn hard stuff in order to get there, I recommend reading Donald Knuth's "The Art of Computer Programming".  It's hard stuff, but it will make you an excellent programmer, not just a good one. (But don't do this until you've learned the basics first, so read the previous two books first, and get lots of experience writing lots and lots of code.)


T

-- 
Never trust an operating system you don't have source for! -- Martin Schulze

H. S. Teoh:

> The way to improve your coding skills is just to write
> lots and lots of code. The more you write, the better
> you'll get at it.

Doing lot of exercise is not nearly enough. You also must do them "smartly". And it's far from obvious what that means. And most schools, movies, TV and most friends don't give you an idea of what that "smartly" means.

I believe that a lot of what tells apart the common people from the people that have mastered their field is that (future or present) masters have found good ways to train themselves. One example of such "smarts" is that you have to keep pushing yourself forward, working mostly on the parts that you find less easy to do.

There so many wrong ways to teach to ourselves, it's hard to do, and it's very easy to get struck in local maxima. And what's worse, often such local maxima are hard to tell from the true maxima, that is the mastering of a field :-)

Bye,
bearophile

On Fri, Jun 07, 2013 at 01:01:54AM +0200, bearophile wrote:
> H. S. Teoh:
> 
> >The way to improve your coding skills is just to write
> >lots and lots of code. The more you write, the better
> >you'll get at it.
> 
> Doing lot of exercise is not nearly enough. You also must do them "smartly". And it's far from obvious what that means. And most schools, movies, TV and most friends don't give you an idea of what that "smartly" means.
[...]

You're right. My statement is predicated upon being able to learn from your mistakes and progress, but when it comes to coding, it's not always obvious what's a mistake unless you have some outside input.

For example, I first started coding in the ancient Applesoft FP/BASIC, and cut my teeth on writing spaghetti code (the few industrial examples I've seen at the time didn't help either -- that was the way people wrote code back in those days).

It wasn't until I picked up a book on -- of all things -- assembly language programming on the PC, that I learned about modular programming and code reuse -- because without a logical modular decomposition, assembly code QUICKLY gets completely out of hand and unmaintainable. Code reuse was also necessary to make writing non-trivial applications in assembly language tolerable.

However, it was only when I started learning C in university that I first really learned about functional abstraction -- even in my previous modular code, there were tons of globals everywhere and function interfaces were ad hoc and not well-planned. With C, I began to learn how to encapsulate chunks of code in functions. Of course, university CS courses also helped me with learning proper abstractions (y'know, avoiding globals, goto's, etc.).

In my later years in university, C++ first made its mark on the industry, and that was when I first learned OO programming. Around that time I had cut my teeth on writing ray-tracers and B-trees, so I guess you could say my education helped a lot, even if much of it was impractical things like uncomputability theory -- certainly an interesting subject, but it's a bit sad if a CS graduate knows more about uncomputable problems than computable ones! (I have actually seen people like this.) In grad school I wrote a compiler in an elective course, and a decompiler for my thesis (haha, the irony). By then I had learned several other languages, including Concurrent Clean, Perl, Java (the earliest versions), and a bunch of others.

Then I went into the workforce, and that was when I first encountered a "real" software system... and saw all of the infelicities that goes into making a commercial product alongside the ingenius ideas. That really drove me to reflect deeply about maintainability and proper software design. Ultimately it would drive me to look for a better programming language that would be both practical, encourage proper programming style, and still retain close-to-metal performance.  Eventually this led me to D. :)


T

-- 
Klein bottle for rent ... inquire within. -- Stephen Mulraney

Thanks for all the fantastic replies, now I'm really glad I asked.

Ali, I'm already reading your book and it's pretty good. I've also ordered The D Programming language, so that should be a big help. The only thing that remains is patience I guess. I won't give up on D so easily this time.

Thanks a lot, really

On Friday, 7 June 2013 at 13:45:50 UTC, Daemon wrote:
> The only thing that remains is patience I guess.

That, buy Andrei's book and ask questions here. :)

http://www.amazon.co.uk/The-Programming-Language-Andrei-Alexandrescu/dp/0321635361