This Week in D #15: hackathon, mem management, ARM, tip for C coders

[Adam D. Ruppe via Digitalmars-d-announce]

I covered two weeks this time, as I missed last week.

http://arsdnet.net/this-week-in-d/may-03.html

The tip this week might be a bit controversial but I actually 
feel kinda strongly about this. So many times, I see people 
asking questions about how to do task X in D.

I think that's the wrong question: you should just be asking how 
to do task X. The programming language isn't terribly important: 
if you can do it in C, you can do it in D basically the same way; 
D provides similar language features to other common languages 
like C and Java, so a LOT of knowledge carries over from them... 
as long as you aren't afraid to use it.

I think that when people are new to D, we ought to press this 
carry-over point. They don't have to forget everything and 
suddenly do everything the D way, using only Phobos, doing it all 
with lazy ranges, etc. It doesn't have to be all that new, 
unfamiliar territory at once.

Similarly, I get a bit bothered when I see a lot of work done to 
add a bit of common functionality to a C library. Now, don't get 
me wrong, I reinvent the wheel as much as the next guy (actually, 
I don't even like the term "reinventing the wheel" exactly 
because so much knowledge carries over. Just because I'm 
re-coding it doesn't mean I'm reinventing it. By carrying over 
knowledge of the problem domain from any source, it makes coding 
it again a lot easier - I already know what needs to be done and 
where the pitfalls are, unlike a truly novel invention, where all 
that is a mystery going into it. But I digress).

I almost never use third party libraries personally for a variety 
of reasons, so I get the desire to rewrite things, especially 
when D offers so many ways to do it better than ever before.

But at the same time, I'm  also a working programmer accustomed 
to things like last-minute client requests, deadlines, and other 
schedule constraints (including just simply not *wanting* to 
spend that kind of time on a problem, believe it or not, I don't 
actually care for programming all day every day....)


In these cases, being able to say "yes we can, and I can do it 
today, though it might look like C" is so much more valuable than 
saying "maybe... if I figure out how to make it idiomatic D"



So I guess it is more a peeve of mine than anything else, but I 
wanted to talk about it anyway and used the tip of the week as my 
vehicle. D code that looks like C isn't a bad thing, indeed, I 
think it is a selling point.