On Sun, Apr 3, 2011 at 2:17 PM, Everett L Williams II
<rett / classicnet.net> wrote:
> *Let's not pay too much attention to the code snobs on here. I've yet to see
> a recursive function that is more efficient than a more linearly coded
> function that accomplishes the same thing, and there is always the problem
> of curtailing recursion. People often mistake shortest code for the most
> efficient or effective, and that is seldom true.

Which you are doing at the moment, it appears. It's a straw man,
anyway: nobody was talking about performance.

> In addition, there are a whole host more people who can write acceptable programs in Excel than there
> are who can do so in Ruby or probably the sum of all the languages that are
> in that category.

Extraordinary claims require extraordinary evidence. So, show the
evidence, please. Also: define "acceptable".

> If you are after the 80-90% of intel x86 compatible machines
> that run Windows, that is not an issue. I won't even say that maintenance is
> a bigger problem in Excel, though the issue can be argued in many different
> ways.

How many of these machines run Excel, and in a compatible flavour to
whatever you want to sell based off of Excel?

If we are arguing market segments, we all should be writing software
in ActionScript, and distribute Flash files (95% or so market
penetration across all x86 machines installed world-wide, and a major
chunk of the Android market in smart phones).

> Once you have made up your mind to use a tool like Ruby, you have to pick a
> flavor, and you really need to know C/C++ as well as Ruby to really be able
> to use Ruby. If you intend to have cross-platform support, you need to
> understand the subtleties of the various platforms you intend to support,
> which is a problem in almost any language. Perl and Python and especially
> java should also be considered, especially if there is a history of coding
> in one of those languages within your organization. All that aside, Ruby is
> an excellent and well supported tool, well worth your time and effort, but
> something that should be considered is that the simplest tool that is
> effective should usually be used. Good luck.

Yeah, and I doubt that in 99% of all cases that aren't spreadsheets or
statistics, Excel is the tool one should use.

Anecdote:
My EE prof used Excel to invert a matrix. Took about 30 minutes, and
was far from obvious (I forgot how it was done, since it was
definitely something Excel wasn't designed to do), when a specialized
tool (Maple in this case), did the same job in one line of code,
following the mathematical notation (M_inverse := M^-1).

Thus, I wouldn't use Excel to write a tool to analyse an electrical network.

-- 
Phillip Gawlowski

Though the folk I have met,
(Ah, how soon!) they forget
When I've moved on to some other place,
There may be one or two,
When I've played and passed through,
Who'll remember my song or my face.