Why Ruby?

[Michael Stover]

>
> 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 <jmdavisProg at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20101211/7a575244/attachment.html>