From: Chad Perrin Date: 2011-04-04T23:39:37+09:00 Subject: Re: Lambda Shambda --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 ] --azLHFNyN32YCQGCU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk2Z1L8ACgkQ9mn/Pj01uKX8gACgjRpZj3kQKLnmB9ZzLg8Na/8e fT0AnjToB2/BfWGtry9uu0qZpFcJbHzQ =LpP4 -----END PGP SIGNATURE----- --azLHFNyN32YCQGCU--