-11564

035032

Snctns isnt Pwr

Not a Commentary	This paper isn't intended to rehash the discussion present in the earlier commentary. Part of the complaint about that paper is that it is quite unnecessarily narrow, and it is hard to expand the domain of consideration with only comments written about existing material.
Dimensions to Succinctness	The first, and perhaps most central, problem that needs to be resolved is the question of just exactly what we are applying the notion of `succinctness' to when we discuss programming. There are at least three possible, and quite different, dimensions.
	In Programs	First, and perhaps most obviously, there is the notion of `succinctness' in the programs written in the particular language in question. Even within this narrow aspect of programming, the issue is not simple.
		Sensitivity to Domain: The question of whether a particular program is terse or not may have a lot to do with the domain of the problem and how it fits with the language in question. A simple picture of this may be created by visualizing the treatment of the assignment of a computed value in two ancient languages like FORTRAN and pre-compute verb COBOL. Here assignments in FORTRAN are quite terse and to the point while an equivalent statement in COBOL involves lots of words describing the calculation. So most people would suggest that FORTRAN is more terse in this regard. On the other hand, there are other problems domains, perhaps the processing of `records' is an example where we would say COBOL was more terse and straightforward.
		Sensitivity to Programmer: And then there's the question of the effectiveness of a particular programmer in exploiting the characteristics of the language he/she is programming in. Some programmers---generally those who know a particular language well---will write terse and effective programs, while others will not know their `tools' so well and will therefore generally write programs which are less clean and straightforward.
		Interaction Effect: As if this was not already complicated enough, there is also an `interaction' effect between programmer and domain. Indeed in studying this area we run into this particular problem again and again. A particular programmer may be able to use a particular language to deal with a particular problem in ways which are more or less effective. It is very difficult to deal with this complex of interaction in any very general way.
		Perl Golf: The existence of `perl golf' makes it clear that succinctness may be more a characteristic of how we use a language than a property of the language itself. `Golf' is the game of getting a particular program down to a most succinct representation. One of the characteristics of the perl language is that it makes this possible to a rather absurd degree. While succinctness is the primary goal of perl golf, it should be noted that a certain amount of willful obscurity also enters the picture. While I think few people would put `perl' in a list of `succinct languages', there are circumstances where it is used in a fashion that leads to amazingly succinct programs.
	The Language Itself	A second aspect of `succinctness' deals with the language itself. In the language K, for example, even the `IF' function is represented by `:' and it's hard to get more terse than that without involving mind-reading. Even here there are a couple of separable aspects of the problem worth considering.
		Operators: One dimsnsion of succinctness deals with the length of the `operators' and with the structure of definitions. In some languages, for example, `+' not only represents addition, but also may represent string concatenation which might require subroutine calls in other languages. And single operators are about as terse as a representation can get. J is an example of a language where the authors ran out of operators and went on to add a whole class of `operators' by suffixing single characters with periods or colons.
		Invitation to Terseness: Another relevant consideration is whether a particular language may `invite' terseness or not. This is, of course, largely an issue of the relationship between a programmer and a language, but there may be some general aspect to the question of whether a particular language `rewards' terseness---for example by making something more readable---or not.
	In Description	Third, a possible definition of `succinctness' in a language deals with the volume of the body of information needed to document the language. Some languages require volumes to document their characteristics and behavior. Others, and here K comes to mind again, can be documented on half-a-dozen screens of 20 lines. In the latter case I'm not talking about a complete Reference Manual level specification, of course, but enough documentation to be very effective.
The Good in Succinctness	It's easy for me to concede a lot of good in succinctness. I have always had a strong personal feeling for succinct languages starting with some of the languages we designed for the IBM1130 and carrying on through APL, J and K. And I have not only worked with, but taught, such languages to well over a thousand high quality students at of soem first-rank universities. So I am reasonably familiar with succinct languages. And I like using them. There are many reasons.
	Comprehension at a Glance	First, if a language is terse, then it is possible to `see' a large chunk of it at once. If we can condense code that might otherwise take many pages down to just one page, then we can see the whole of what is going on just by looking at that page. This doesn't mean, of course, that it will be easy to understand that page. Things that are essentially difficult will remain being essentially difficult.
	Writing Shorthand	Graham suggests It seems to me that succinctness is what programming languages are for. And surely it is one possible goal. The idea that `writing less' is easier on us than `writing more' is superficially at least an attractive one. If ideas are coming to us at a rate greater than the one at which we can record them, then the less we have to write the faster we can get our ideas captured. As, we'll see in moment, this may, or may not, be the case, but for the moment we'll let it go.
	Spotting Generalizations	Code which is succinct may also allow some of us to spot useful generalizations. These may be harder to see if they are spread across a large number of pages. Part of a key trigger that allows some people to find generalization is a simply physical act of seeing a regularity, and if elements that might `match' are spread too far apart they may be hard to notice. So succinctness helps here as well.'
Some Arguments Don't Work	But there are a lot of situations where succincness is, per se not of much help. While some people really love succinct languages, and give testimony that might we worthy of a member of a religious cult, others fail to find succincness very attractive. It appears to be quite a personal matter.
	Lessons from Teaching	Factually speaking, succinct languages don't sell particularly well. Over the years I have taught programming to thousands of students. These were students at elite colleges. And even here, the number of students who went on to make any particular use of succinct languages proved to be quite small. People voted with their feet.
	Formulation vs. Use	Implicit in Graham's arguments is a distinction, not makde very clear, between the importance of the influence of language on the problem solution process as opposed to the impact on the process of `understanding' a problem doman. Quite clearly these are different matters. Quite clearly these are different matters. A language can prove to be very effective in helping us solve a particular problem without, in any way, contributing to our deeper understanding of that problem. Alternatively, a language could, I suppose, help us understand a problem in a more profound way without, in any sense being able to help us actually do anything about it. Thus we can easily imagine something that helps us understandi a problem without, in any way, helping us do something about solving a problem.
	Language vs Expressions	At the core of these issues is the question of whether we are concerned with questions about the nature of the languages itself, or with particular programs---expressions---in the language. Is it the language, or particular expressions of procudures in the language that are `succinct'. It is not at all clear that there is any useful way to separate these questions.
	What we already Know	Praying at the altar of succinctness also doesn't pay adequate attention to users who make use of prior knowledge and understanding in their problem solving process. Skills and capabilities that a problem solver already has probably dominate issues like succinctness in choice of language when it comes time to work on real problems. Old tools are sometimes comfortable and allow us to rapidly focus on the problem we are trying to solve, rather than on the tools themselves.
	Doing vs. Thinking	Then there is the question of how separable `thinking about programming' is from programming itself. In other words, Graham is often unclear about whether he is more interested in solving a particular programming problem, or generalizing an understanding of a problem domain. These activities often require different amounts of energy and they have quite a different focus. Also, I think it is fair to say that neither of the activities is `superior' to the other in any real way. If we are going to exercise some particular problem solving technology over and over, then perhaps some attention to the higher-level problem of generalization is warrented, but often problems are `one-off' and time spent generalizing accomplishes little of practical consequence other than to keep the meter of client costs running.
	Interactions	And finally, there is the question of all of the complex interactions between these factors. This clouds the issue further, and belies the simplicity of Graham's `succinctness is power'. It is surely a great deal more complicated than that, and any such conclusion is not only too simple, it is too often wrong.
Is succinctness bad?	I have difficulty generating any argument that it would ever be useful to suggest that `succinctness is bad.' In questioning the notion that `succincness is power' there shouldn't be any notion that denial of that particular proposition means that we need hld the opposite. One can be quite comfortable with the notion that `succinctness is good for some' without having to hold that it is bad for all.
A bad generalization	Lurking behind this discussion is what might be a bad generalization. Perhaps the notion that succinctness is power grows from the fact that as we come to understand a problem better and better, our representation of that particular problem often becomes more and more succinct. In the `old days', when computer time was a precious commodity, we used to spend a great deal of time thinking before ever really got around to doing anything. Now, as computer costs have dropped tremendously, there is no longer much of a penalty to wasting computer time, and I find I am much more likely to get some code down, and then re-work it over and over shaping it into a better and better program as I come to understand the problem domain better and better. It is not unusual, these days, for the `first draft' to be much longer than a later draft, even if the later draft solves more of the problem than was tackled by its predecessors. However, this strategy is prone to a particular and peculiar misunderstanding. Namely that the effectiveness of the program is somehow tied up in its succinctness. It is easy to mistake the kind of succinctness that is the result of understanding a problem better and better for the kind of succinctness that might result from particular choices about programming language. Perhaps this is what has led Graham to misfocus his conclusions.
Some Verbose Languages are Good	And, there are some verbose languages which I think ought to be conceeded are good---at least for some of the users. Indeed, some of the most successful languages of the past decade or two would generally be classified as `verbose' by most users. Nonetheless, these languages have often been quite commercially successful. Certainly it is possible to argue that these languages have not contributed a great deal to helping us conceptualize and deeply understand our problems, but then this is generally pretty much a matter of opinion. And if we count votes by any reasonable measure of `language acceptance' then we have to be willing to concede that these languages are more successful.
	Worth spending a moment	Perhaps at least a moment should be devoted to the history of `succinct' languages. History doesn't really treat them very kindly. I doubt if many would classify LISP as succinct, but certainly APL, which we started to use in earnest in the early 1960s would generally fall into this grouping. We taught a lot of APL in the 1960s and early 1970s, and all-in-all have relatively little to show for it. While a few students managed to generate successful careers out of use of this kind of language, the utilization appears to have reached a high water mark in the middle 1970s, and generally has been ebbing ever since. There doesn't seem to have been any long range residual knowledge that resulted from most of these efforts.
	Examples	It's worthwhile looking at some `non-succinct' languages tha at least some people would argue are `good'. While there is surely a `cult' of people who are willing to suggest that `succinct' langueages are a `good thing', there are a condsiderable number of people would equally defend a number of languages that are not-succinct, but which seem to have a considerable number of fans and adherents.
		REBOL: I find REBOL to be a curious language. I am almost always startled with just how much work I can get done in the REBOL environment without a profound investment in understanding either the language or the milieu. This makes it an available piece of technology that has particularly high-yield in the early stages of use. How well this will play out over time is something that only time will tell. Predicting what will happen is not likely to be of anything more than testimonial use. I doubt if anyone would call REBOL succinct. It is quirky and long-winded but very effective at solving an important class of problems.
		TeX: TeX is an interesting example on at least two quite different counts. First, TeX was designed by Knuth, one of America's finest mathematicians. Second, as anyone who has read much TeX source will certainly be willing to testify, TeX is distinctly not succinct. For all of his interest in profound mathematics, Knuth appears to care not one whit about the succinctness of the input source. Of course he does make some heavy use of macros and other pieces of `succinctness technology', but the code not only ends up by not being very succinct, it looks to me that it is clearly written without any concern for succinctness (and written very well indeed).
Power Cliques	It is also worthwhile giving at least passing consideration to the notion of power cliques in programming. It is quite plausible to suggest, I think, that circumstances can arise where a small, but effective, cadre of programmers develops within an organization. Such a group may well choose some particular artifact, like programming language, as an icon around which it can focus its concern and effort. They can become the `in' group and use a particular computer language as a membership ticket to the group. This can easily cause us to misunderstand the causal relationship between programming effectiveness and language. A small, highly comptetent cadre is likely to be successful pretty much independent of whatever modes of work they choose to emphasise. If they focus on a particular programming language, then it is all to easy to believe that the success arises because of the language, rather than the fact that it is quite incidental to the language. It's just the way people normally operate and draw conclusions.
	Learning vs. Being	If you want to have a power clique work on your problem, you can, perhaps, always hire one. It all fine and dandy for some people to be able to use particular languages in a super-effective way. And it's not unlikely that the languages that they might choose to help them solve problems might be unusual in some dimensions, succinctness surely among them. However, this doesn't address the issue of how one increases their power at all. Should one recommend succinct languages to someone who aspires to become a first-rank programmer? Given our current state of knowledge, I'd have to say `No'. It surely isn't the first thing that I'd think about in offering suggestions for training. Since the purpose of this note isn't to suggest training methods for future programmers, I'll let the point drop there. Suffice it to say that I wouldn't recommend succinct languages unless I saw some strong indication that the aspiring programmer alread had a good mind set for understandig some of the more succinct technologies.
Arguments from Art	It might be useful to take a moment and think how the `succinctness is power' notion plays if we think about art. Would we ever say such a thing about writing, painting or composing? Some great art surely is quite remarkably succinct. However, it seems equally clear to me that there is a lot of great art which is not succinct at all. A great poem may accomplish wonderous things in 17 syllables, but there's also great power in some of the gigantic works of Mann or Melville and others. Succinctness may enhance some art, but not to the exclusion of alternatives.
The Concorde Example	If I can stretch an example for a moment, the `goal' of succinctness strikes me as a lot like flying on the Concorde. For me, at least, The Concorde shortened what was the least difficult part of the trip. I used to go to Europe at least half-a-dozen times each year, and for me the difficult part of the trip was getting from my house to the Airport, waiting in the lines at the Airport, waiting for the plane to leave, and then going through a similar process upon arrival. Elapsed time from Home to my Paris Hotel was usually about 16 hours, of which 7 or 8 were spent in the air. Not only was the time spent in the air the least difficult portion of the time to deal with, reducing it by 3 or 4 hours wouldn't accomplish much for my comfort---certainly nowhere near as much as the pain caused by reducing my bank account by an extra $10,000 or so. The relevance to the issue here? Worrying about the succinctness of the language is fiddling with what for me is often the least important part of the problem solving process.
Arguments from the Learning Disabled	I have the good luck to have an old friend who is one of America's leading experts on learning disabled children. A keystone of his career is a simple---but brilliant---observation that while some children may lack particular competences that are made particularly important by the nature and structure of our educational system, they often have other competences and capabilities that lead to whole and fulfilled lives, although they are often of a somewhat different structure than the more conventional life that is effective and appropriate for children with more common capabilities. The core of his observation seems to be that we are likely to profit more by doing well with what we can do well than by trying to do passibly well with things we are not capable of.
	Can't do some things	Applying this world-view to the particular area of concern here, we may find succinct languages to be of some great and effective use to some particular subset of the population, but this fact is of little use to the rest of the population for whom such languages are an uncomfortable and ineffective way of handling problems. And it is not because of any particular disposition on their part, it is rather something just built in to the basic set of competences that they are endowed with from birth. In saying this I carefully note that I have no particular evidence for the fact that these compentences are built in, and relatively immutable, but I also can argue that there is equally little evidence to the contrary. And, given that the evidence is wanting, it seems particularly silly to assume that this is a compentence we all posess. My intuition tells me the reverse is more likely to be the case.
	Can do others very well	It should be noted that people who find succinct languages difficult to use are not incapable of effective work in other domains. It would be an even worse stretch to assume that people who don't particularly care for succinct languages are ncecssarily not as good or effective in their programming tasks than are those who like succinct language. One hardly has to go much further than to point out Knuth as one example, but there are most certainly others. One of my co-authors back in ancient times at MIT used to particularly enjoy, and find quite effective in his thinking process, the production of long pages of largely repetitive code. He was a great thinker and programmer and he found some odd---almost mantra-like---feeling in writing out case after case of some complex analysis. Terse code interfered with his thinking process.
	To each his Own	What this says to me is that it is a very idiosyncratic matter whether you like terse, succinct languages or not. I make not particular judgement that one is better than the other. I happen to share, I rather suspect, with Graham the notion that I like succinct languages, and that they work well for me and help me think about the broader aspects of my problems. But, contrary to Graham's view, I hold no opinion that this is a superios way of thinking about the problems.
Confessional Testimony	So Graham's paper reduces to testimony of a kind not unlike that we might hear in a revival tent. There's nothing wrong with testimony, of course, and some may even be swayed by it. But even though I am quite willing to acknowledge that Graham's testimony is without doubt forthright, I nevertheless has no impact on me, any more than does that of Rev. Falwell, Rev. Sharpton, Rev. Robertson or Rev. Farrakhan, about whom I have equally little doubt are forthright in their testimony. Testimony is no substitute for facts, and shouldn't be mistaken for them.
	Cult Programming	There also seems to me to be a considerable danger of languages which have very succinct representations becoming something of a cult. Over the years I have had to listen to a lot of `my boss doesn't understand' whining about choice of language. A rather remarkable proportion of it comes people who use succinct languages. This emphasises the `cult-like' aspect of these languages.
	Succinctness Technology	Although this is probably not the place for it, it might be interesting to compile a list of `succinctness technology'. This is particular elements of a programming language which might help with the task of generating succinct programs. Supporting macros is one example of such a piece of technology.
Summary	Perhaps unfortunately, succinctness isn't power. I suppose it would be nice if the world was that simple. Succinctness can either add to or subtract from power in a particular situation, depending on how it is applied.