On 4/05/2015 3:23 p.m., Adam D. Ruppe wrote: > 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. I covered two weeks this time, as I missed last week.The tip this week might be a bit controversial but I actually feel kindastrongly about this. So many times, I see people asking questions abouthow to do task X in D.I think that's the wrong question: you should just be asking how to dotask X. The programming language isn't terribly important: if you can doit in C, you can do it in D basically the same way; D provides similarlanguage features to other common languages like C and Java, so a LOT ofknowledge 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-overpoint. They don't have to forget everything and suddenly do everythingthe D way, using only Phobos, doing it all with lazy ranges, etc. Itdoesn'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 abit of common functionality to a C library. Now, don't get me wrong, Ireinvent the wheel as much as the next guy (actually, I don't even likethe term "reinventing the wheel" exactly because so much knowledgecarries over. Just because I'm re-coding it doesn't mean I'm reinventingit. By carrying over knowledge of the problem domain from any source, itmakes coding it again a lot easier - I already know what needs to bedone and where the pitfalls are, unlike a truly novel invention, whereall that is a mystery going into it. But I digress).I almost never use third party libraries personally for a variety ofreasons, so I get the desire to rewrite things, especially when D offersso many ways to do it better than ever before.But at the same time, I'm also a working programmer accustomed tothings like last-minute client requests, deadlines, and other scheduleconstraints (including just simply not *wanting* to spend that kind oftime on a problem, believe it or not, I don't actually care forprogramming 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 wantedto talk about it anyway and used the tip of the week as my vehicle. Dcode that looks like C isn't a bad thing, indeed, I think it is aselling point.