Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!zaphod.mps.ohio-state.edu!think.com!samsung!transfer!lectroid!jjmhome!smds!sw From: sw@smds.UUCP (Stephen E. Witham) Newsgroups: comp.lang.misc Subject: Re: scheme [Re: What does an anti-perl look like] Summary: Write-onliness is a language feature Message-ID: <584@smds.UUCP> Date: 24 Jun 91 14:23:27 GMT References: <2714@amix.commodore.com> Organization: SMDS Inc., Concord, MA Lines: 37 In article , rockwell@socrates.umd.edu (Raul Rockwell) writes: > Anyways, the point [or the "insight", if you prefer] was that > "write-only" is a reflection on programmer skill in a language more > than a reflection of the language itself. (Disclaimer up front: I work for SMDS, with Richard Harter, who wrote Lakota and is in this discussion. The following isn't a plug for Lakota in particular, though.) I disagree strongly. When you write a program, you transform your ideas into a form that the computer can use. In some languages, the transformation scrambles the evidence of the original thinking process. In other languages, it's better preserved, so that you can go back and pick up where you left off. You might say that a "good" programmer can write a clear program in any language. This deserves two responses. The first is that the design of a language (or anything else) should have its users in mind. If the typical, or natural, way programmers use a language is write-only, then that's the language designer's fault. Blaming users for the faults of our designs is one of the crappiest tendencies of computerists, and it's not mitigated by applying the same macho ethic to ourselves as users of languages. So, perhaps a programmer could write a clear program in a given language, but if the language makes this hard for some people, or if it takes a long time for them to learn how to do it, then the language is write-only for those people. Second, it's not true that you can write any program clearly in any language. In the process of making a program "clearer" in a bad language, all you can do is add complexity--extra variables, extra lines, extra function definitions, extra comments--and make the program bigger, with more parts. This pushes details over the horizon, so that at any one point, you can see less and less of the relevant detail you need (and more and more stuff that's just compensating for the weakness of your language). --Steve