From: Chad Perrin Date: 2011-04-08T06:37:39+09:00 Subject: Re: functional paradigm taking over --AhhlLboLdkugWU4S Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 08, 2011 at 12:51:35AM +0900, Everett L Williams II wrote: > Chad Perrin wrote: > >>Denigrating another person's choice of tools will certainly not make > >>that person likely to seek your advice again, nor consider you > >>helpful. > > > >I don't think anyone is denigrating the use of spreadsheets for > >problems best solved by spreadsheets. People just object to > >describing MS Excel as a better programming language than Ruby -- a > >pretty tall order, given it is woefully inadequate to many tasks for > >which programming is done, and is not in fact a "language" by any > >definition short of the sort of mental gymnastics necessary to discuss > >4GLs with a straight face. > > *Somebody earlier suggested listening to Robert Martin's address to the > RailsConf, and I did. It speaks to what can destroy a language, and it > pretty much delineates the types of attitudes that are being brought > forward here. Excel is being denigrated here, and that is foolish. Many > people use spreadsheets all day long to accomplish their work. They are > good with spreadsheets and comfortable with them. You clearly didn't read a word I said. I haven't listened to Martin's address (yet), but something tells me he was not talking about the idea that pointing out some tools are better for certain jobs than others as an attitude that can destroy a language. I'm pretty sure he never said that calling something what it is -- a spreadsheet application, as opposed to a language -- is in any way toxic to a community. Maybe we should start calling Ruby a DBMS, and PostgreSQL a spreadsheet, too. Would that make you happier? Of course, then we'll no longer have any names for different types of tools that carry any meaning, because the names will all be interchangeable. > > What is being said here is that they should throw away all that > goodness and go to Ruby or something like Ruby, because it is better > for some classes of problems. What is being said is that for some classes of problems Ruby is a better choice -- and, in fact, for some classes of problems Excel is no choice at all. For other classes of problems, Ruby is no choice at all. Why do I think you'd dispute the notion that people should use Ruby for all spreadsheet tasks, even if you get up in arms if someone disputes the notion that Excel should be used for all programming tasks? > > That's a little like taking a jackhammer out to get rid of the spots on > your garage floor. Since most of these people will never need to > program something that they cannot do in Excel, even if awkwardly, that > seems foolish. Where are you getting the crazy idea that anyone said everybody who uses Excel should stop using it for anything at all, and use Ruby instead? Your straw men are looking pretty shabby. > > Because of their familiarity with the tool they use most often, they > can accomplish more with it in an hour than they could in days working > with Ruby. No matter what tools you use to work with Ruby, it is a > complete paradigm shift, and that is difficult for the average person > who does not consider themselves a professional programmer. It may have > taken them years to learn how to do what they now do in Excel, and > Excel is only a stalking horse for a wider point here. >=20 > If your current tools, whatever they may be, are slowing or blocking > you sufficiently that you must go to a new tool, or if you need an > excellent tool for future work, something like Ruby makes all the sense > in the world, but every advocate of something like Ruby should realize > that Ruby is not an endpoint. I don't think anyone said otherwise. You're responding to points nobody made. > > In the fairly near future, we are going to progress to machines that > never turn off and never reboot, and that do not distinguish > applications. Ruby nor any other current language is equipped to deal > with that type of environment. I think a lot of people would disagree with that remark. In fact, Alan Kay once likened turning off a computer, ending a process, et cetera, to metaphorical murder (I'm pretty sure it was Kay, anyway -- someone correct me if I misremember). The idea was thata lot is invested in each set of running state, and throwing all that away just to restart it again later was a criminal waste of resources. Continuity can offer substantial rewards to not only resource usage, but also the development of more productive computational models. Object oriented programming offered the beginnings of a solution to that problem, where objects are effectively perpetual until one of them is truly, utterly unneeded thereafter, and the ephemeral needs of the system are served by message passing instead of by creating, manipulating, and destroying collections of operational state. This, to me, sounds like Ruby may be on the right track toward serving exactly the sorts of needs you imply here -- far better than any spreadsheet application, at least. > > Things like genetic programming and fuzzy logic and really, machines > that "think" like we do are the goal. Now I realize that eyes are > rolling and so forth, but what I am trying to say is that Ruby is not > nor will it be in that world, and that future is coming far faster than > most imagine. Ruby in its current form . . . maybe not. It's a step in that direction, though. What do you have against Ruby that you want to throw it away before it has given birth to all the more-advanced children it has the genetic material to spawn? What does this have to do with the laughable idea that MS Excel is a language? Oh, sure, Excel is surely the world's most popular end-user spreadsheet application, and for a number of good reasons, but that doesn't mean you get to start calling it a language, an operating system, or a microwave oven without people giving you funny looks. > > If you get your nose so stuck down to the grindstone that all you can > see is Ruby, then you will eventually suffer the same criticism as is > being thrown at the guy who is using Excel at the moment. Working like > the devil to make Ruby better, and to make it more accessible, are > worthy expenditures of energy. Being offensively defensive about it and > parsing definitions about what is and is not a programming language are > complete wastes of time, and are self defeating. 1. I'm looking at lots of things -- not just Ruby. 2. I'll probably be using something else more than Ruby in three years (Go, maybe?). 3. There's nothing offensive about pointing out that MS Excel is not a "language" any more than there is in pointing out that my laptop is not a cloud storage service, nor about pointing out that Excel is a better spreadsheet application than Ruby but a worse general purpose programming tool. 4. If we do not differentiate between different types of tools (programming languages vs. spreadsheets), we will suffer for our inability to discuss our tools meaningfully. >=20 > At the moment, Ruby is not threatening to displace even COBOL and > ForTran, much less C/C++ and Assembler, and there are hosts of simple > tasks that really should not be done in Ruby or anything but a 4GL, you > know, that target of a derisive earlier comment. I don't disagree with any of that. There are many tasks for which I would never use Ruby. That doesn't mean that something that has no systemic grammar a "language", though -- even if that thing is better for certain tasks than something that *is* a language, like Ruby. I wouldn't use a language to hit a baseball, after all, but that doesn't make a baseball bat a "language". The thing that makes 4GLs most laughable is the idea that they're "fourth generation". Think for the moment about what "generation" means. Someone really jumped the gun assigning the term "fourth generation language" to what amounts to GUI wrappers for macro languages, probably assuming that somehow the approach taken to designing these things would ultimately lead to the ability to write operating system code without having to know anything about operating systems some day. > > I used one of the very first 4GL's, Easytrieve, and it allowed me to do > in 15 minutes, what COBOL programmers were taking weeks or months to > accomplish (note that I did not say good COBOL programmers). For > reasonably complex data changes or for reports, it was literally an > order of magnitude or two better than COBOL, and there are days that I > would give my right arm to still have it. It is commercial and costs > more than I can afford for my purposes. In the mean time, I really > don't want to write reports in Ruby, though I realize that it is quite > possible, and simple data fixes in Ruby, especially on new files for > which I don't have schemas, aren't. I'm not really sure what you're trying to say about what is and isn't possible in Ruby with the end of that last sentence, and I don't know what the fact you found a 4GL very useful within its narrow domain of intended applicability proves that might be contrary to anything I said. --=20 Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] --AhhlLboLdkugWU4S Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk2eK5MACgkQ9mn/Pj01uKUTxACgw4QTb8+IZMoxkCm6Mr0gqtsc p4wAoNARuvWgKrSJ0cD3+kMuAmHOT6nq =iC+D -----END PGP SIGNATURE----- --AhhlLboLdkugWU4S--