Re: Lambda Shambda

Phillip Gawlowski wrote:
> On Sun, Apr 3, 2011 at 2:17 PM, Everett L Williams II
> <[e-mail]>  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.
>    
*And, of course, since we were talking about making a practical decision 
about which tool to use, performance cannot possibly matter. There is 
also this overriding compulsion amongst coders to produce the most 
abbreviated code possible, assuming that such demonstrates their special 
skills and that such code is the most desirable. Any study of 
algorithmic efficiency will show clearly that the shortest code is 
almost never the fastest code, especially in unoptimized code.*
>    
>> 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 this were an extraordinary claim, your comment would hold true, but 
only exceptional arrogance would cause any other claim to be made. 
"Acceptable" means satisfactory to the person doing the programming, who 
is usually some grunt just trying to get his job done, rather than 
someone who is a proponent of any particular thing. I'll try not talk 
about "fanboys" here.*
>> 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?
>    
*When I am responsible for something, unless some feature in the current 
version is absolutely necessary, I tend to drop back one or two versions 
to cover most of my market, not to mention to avoid the hazards of being 
on the bleeding edge.*
> 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).
>    
*You said it. I didn't. Remember what I said about using the simplest 
tool that will get the job done.*
>    
>> 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.
>    
*Having made the progression from Assembler to COBOL and FORTRAN and on 
to dozens of other languages, I would have agreed with you until I 
started seeing people write all sorts of stuff in Excel. Again, I would 
never have recommended those uses, but they seemed to do the job.*
> 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.
>
>    
*No, if I were going to do a lot of work with matrices, I would use 
Mathlab or one of the various libraries that specialize in that kind of 
work. Actually, "I" would probably use APL or one of the variants, 
because it is flatly designed for work with matrices and can do in one 
line what would take a whole page of equations. Of course, I wouldn't 
really recommend APL, because it is one of those languages that is 
almost impossible to maintain if you did not write it yourself. APL is 
famous for having working code that no one can figure out. On the other 
hand, matrices are not the only method for working such problems. From 
what I know of it, I wouldn't use Excel for huge classes of problems, 
but some people seem to be able to twist it to do things that I would 
never have guessed. "To the man with a hammer, everything looks like a 
nail."...even when a screw or glue might do a better job. The point is 
that he knows how to use the hammer and can get prodigious amounts of 
work done with it, so he has to think very carefully when someone tells 
him he has to learn this new and completely different tool while the 
work gets behind.

About 50% of the real newbies to programming who come on this site with 
a complex project that requires unstable parts of the Ruby pantheon, 
should be told to use another tool, one that is simpler, more mature, 
and that does a better job of handholding, but people who spend most of 
their time on Ruby tend to think with their hammer, so to speak, or 
maybe, they don't really know anything else.

Everett L.(Rett) Williams II

Everett L
*