Re: Lambda Shambda

On Mon, Apr 04, 2011 at 06:23:24PM +0900, Everett L Williams II wrote:
> Phillip Gawlowski wrote:
> >  =20
> > 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.*

Programming is about automation.  The most important things about
automation are:

1. reducing the workload on humans (for lack of a better term for those
whose workload we're trying to reduce -- I wouldn't want to discriminate
against dolphin programmers or the artificial intelligences of the
future)

2. using automation abstractions that can be leveraged to produce
additional, higher level automation abstractions further down the line

While software performance and resource consumption are certainly factors
to consider here, they are not the *only* factors to consider.  If it
takes me a month of eight-hour days to write a program that saves each of
thirty people three seconds out of every day, and isn't interesting
enough code to ever provide measurable leverage for further automation,
that'll pay off in about twenty-six years of use, no matter how well the
code performs.  If it takes me eight minutes to write it because I didn't
worry about the performance of my code, though, it'll only take about
five days to pay off; everything after that is pure automation profit.

Obviously, this is a simplified example, but simplicity often makes a
clearer point than belaboring the minor details.


> >
> >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.*

I don't know if I would say that the claim there are more people who can
use MS Excel to automate things is extraordinary, in and of itself.  I
also think there are people who perform automation tasks in MS Excel that
are "acceptable" by some reasonable measure.  If you combine the two, to
claim that there are more people who can automate tasks in MS Excel that
fall within the strengths of Ruby as a programming language to a level of
reasonable acceptability that is equivalent to what Ruby programmers
produce, however, I think we're slipping into the realm of the
extraordinary.

Do you really think it is not extraordinary to claim that MS Excel is
even an acceptable tool by any kind of reasonable criteria to use for
tasks like writing the portupgrade tool for FreeBSD, developing a Web
framework that speeds and organizes the process of developing
applications the way Rails does, or supports code organization that
improves the maintainability of applications the way Ruby's object
oriented programming facilities do?

I do not think we even need to touch the subject of whether there are
more people who can do such things in MS Excel than can do them in Ruby;
it is sufficient to examine the potential for doing such things in a
reasonable, practical, "acceptable" manner in MS Excel, as compared with
that potential in Ruby.  That simple examination alone makes me think MS
Excel falls well short of the mark.  As far as I can tell at the moment,
the *only* way we can define the challenge set before us so that there
are more people who can write "acceptable programs" in MS Excel than in
Ruby is by defining "acceptable programs" in such a limited manner that
it does not require anyone to actually do any programming to speak of.
Filling in a spreadsheet, assigning formulae to cells, and writing a
couple of macros hardly compares to what the vast majority of even
mediocre Rubyists can do -- and, frankly, the same data manipulation
tasks that MS Excel supports via filling in the spreadsheet, assigning
formulae to cells, and writing a couple of macros can be done much more
quickly and easily in Ruby by a mediocre Rubyist than in MS Excel by a
competent Excel user.

So . . . I suppose you could answer the request to define "acceptable" in
a manner that makes it a less extraordinary claim, but I am skeptical
that doing so would provide a response that looks remotely reasonable.


> >  =20
> >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.*

That you do not recognize the absurdity of the suggestion that we write
everything in ActionScript and distribute it in Flash files seems
indicative of your unwillingness to consider the impracticality of using
the wrong tool for the job -- which would explain this dogged attachment
to the idea of using MS Excel to do "programming".


>
> *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.*

By the same token, a hammer can be used to drive screws into wood, but I
wouldn't recommend it -- even if it seems to be doing the job for someone
who clearly does not know any better.


>
> 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.

=2E . . or maybe he should get someone willing and able to use a better
tool to do the job.


>=20
> 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.

Telling people "You can't handle Ruby -- go back to Excel!" is hardly a
good way to encourage people to learn and enjoy the use of new tools.  If
people want to learn new things, I think discouraging them from doing so
just because you think they should stick to VBA macros is nigh-evil.

--=20
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]