> > LOL. I'd _love_ to use D at work, but so much of our code is in C++ and > must
compile with Visual Studio that the fact that C++ doesn't integrate with D all that well and the fact that you have to use dmc on Windows for the C or C++ code if you want to link it with D code make it so that it doesn't make any sense at all to use D at this point. Having to use the dmc compiler on windows in order to leverage legacy C++ code while being able to move on with new D code doesn't sound like too much of a restriction. Is there a similar tool that allows linking D and C++ on linux and mac? Mike On Sat, Dec 11, 2010 at 3:32 AM, Jonathan M Davis <jmdavisp...@gmx.com>wrote: > On Saturday 11 December 2010 00:01:35 Andrei Alexandrescu wrote: > > On 12/10/10 10:16 PM, Christopher Nicholson-Sauls wrote: > > > On 12/10/10 19:26, Ary Borenszweig wrote: > > >> http://vimeo.com/17420638 > > >> > > >> A very interesting talk. > > >> > > >> I used to like D. To write code in a high level while at the same > > >> time being very close to the machine, with class invariants, unit > > >> tests and many other features seemed very appealing. But I always > > >> felt there was something wrong. > > >> > > >> About a year ago I met Ruby. Now I find languages like Java, C#, > > >> Python and D kind of ugly and uncomfortable. Why? Exactly because of > > >> what it is said in that video. > > >> > > >> This is not to start a flame war or trolling, it's just to show you > > >> why I changed my mind so much about D, and why I think (IMHO) you > > >> should care about naming conventions (like bearophile says), more > > >> powerful unittests (and not having unittests integrated into the > > >> language but rather being able to build your own test frameworks > > >> with ease) and stop caring about being C-syntax friendly. The world > > >> doesn't need that many semicolons and parenthesis. :-) > > > > > > I'm a strange one. I use Ruby, and D. (And a couple of others...) I > > > use the tool that feels best for the job, whatever that may be at a > > > given time. Sitting on a disc somewhere are some personal tools I used > > > to use when working with D... which are themselves written in Ruby (and > > > bash script, but hey). > > > > > > Then again, I'm the same one who really really likes Ruby on Rails... > > > and yet still does most things with PHP. Why? Well for one, because > > > for plenty of projects, Rails is less an aid and more a hindrance. > (And > > > yes, before someone brings it up, I'm well aware of CakePHP... and > don't > > > care for it much.) > > > > > > There are times in D when I find myself wishing, momentarily, for the > > > loose typing of Ruby... but then there are times in Ruby when I find > > > myself wishing for stricter typing. > > > > > > There are times when I wish D had open classes... but then there are > > > times when Ruby's open classes give me headaches. > > > > > > I could go on like this... but the point was really just: use the right > > > tool for the job. Keep several tools in your toolbox. There is no > "THE > > > BEST LANGUAGE OMG!!!" There is just the best one for a given > programmer > > > in a given scenario. Some of the things I've done could probably have > > > been better written in, say, Pike! But I don't really know Pike (very > > > well), and don't feel the need to learn it just for those few things > > > that might have benefited. > > > > > > -- Chris N-S > > > > Agreed. One issue with the talk is non-acceptance of "the right tool for > > the job" (the speaker literally says he's tired of that phrase). There > > is one best tool - and that's Ruby. Ahem. > > LOL. I'd _love_ to use D at work, but so much of our code is in C++ and > must > compile with Visual Studio that the fact that C++ doesn't integrate with D > all > that well and the fact that you have to use dmc on Windows for the C or C++ > code > if you want to link it with D code make it so that it doesn't make any > sense at > all to use D at this point. > > And of course, there are plenty of cases where a particular language is > just > incredibly well suited for a particular job, and the best general purpose > language just isn't as good. > > I think that it's good to strive to a have a language that is excellent for > most > use cases, but ultimately, you always have to pick the best tool for the > job. No > language is the best for all scenarios even if it's the best for most > scenarios. > > - Jonathan M Davis >