It's a mistake to ignore the customer [LWN.net]

It's a mistake to ignore the customer

Posted Dec 7, 2012 17:48 UTC (Fri) by sorpigal (subscriber, #36106)
In reply to: It's a mistake to ignore the customer by jezuch
Parent article: GNU Guile 2.0.7 released

Familiarity is a huge advantage that ought to outweigh almost anything. If, in the end, you have to spend a lot of time to understand how to write what you want, more time to read what you have written and even more time to read what someone else wrote, then you have consumed enormous amounts of time that could have been spent doing the actual work of telling the computer what to do. The time and attention of a developer is the single most valuable resource when developing just about any software today. Anything which decreases the amount of time it takes to understand a piece of code (whether writing or reading) increases productivity, all else being equal. It adds up.

(Log in to post comments)

maybe not only familiarity

Posted Dec 7, 2012 20:57 UTC (Fri) by tpo (subscriber, #25713) [Link]

People in support of infix in this thread are using "familiarity" as an argument whereas critics are arguing that infix is *one* aspect of the Scheme language that you have to familiarise yourself with.

I'd like to propose that infix (maybe as well as prefix) as a way of thinking and understanding may be rooted in the human brain itself.

I've just read the "DCI manifesto" on Artima, where the authors are arguing that humans are understanding in terms of things and behaviors. Consequently they propose to model "things" and "behaviors" separately.

As a functional language Scheme would be on the outmost "behavior" side of the possible spectrum. Under the above stated theory it would be a compliment to the human brain that it *is* able to manipulate a symbolic problem representation that is very much focused on only one side of "things and behaviors". On the other hand it would hint to why prefix notation is hard to handle for humans - it supposedly simply doesn't match the "natural" way a brain works.

I'm completely ignorant about that topic and respective research and as such could be completely wrong, however I think we should not stop our thinking at the relatively trivial "familiarity" argument but ask whether the problem could be rooted deeper than that.

[1] "The DCI Architecture: A New Vision of Object-Oriented Programming"
http://www.artima.com/articles/dci_vision.html

maybe not only familiarity

Posted Dec 10, 2012 8:38 UTC (Mon) by jezuch (subscriber, #52988) [Link]

> On the other hand it would hint to why prefix notation is hard to handle for humans - it supposedly simply doesn't match the "natural" way a brain works.

At best it's hard to handle for speakers of SVO languages. It's like arguing that Arabic (a VSO language, equivalent to prefix notation) or Japanese (a SOV language, equivalent to suffix notation) are "hard to handle" and "don't match the natural way a brain works". Try telling that to the Arabs and Japanese ;)

maybe not only familiarity

Posted Dec 10, 2012 9:24 UTC (Mon) by tpo (subscriber, #25713) [Link]

I'm not familiar with VSO languages: do they also, as Scheme does, put *all* verbs at the start of the sentence in case of nested statements? As in:

(do (another_do (yet_another_do (and_more_do (and_still_more_do arg arg

aka

verb1 verb2 verb3 verb4 verb5 subject1 object 1 subject2 object2 object2a

I honestly do not know, but I'd guess even a VSO language will not work that way as opposed to Lisp'ish languages?

maybe not only familiarity

Posted Dec 10, 2012 17:06 UTC (Mon) by nybble41 (subscriber, #55106) [Link]

Deeply nested expressions are a problem in any language, moreso in natural languages which are not traditionally formatted to highlight the subexpressions. If you find yourself writing such expressions in Scheme, you may want to look into refactoring the code, or at least taking advantage of the "nest" macro to flatten the expression. An example:

(do arg1
    (another_do
      (yet_another_do
        (and_more_do arg2
                     (and_still_more_do arg3 arg4)))))

is equivalent to:

(nest [(do arg1)
       (another-do)
       (yet-another-do)
       (and-more-do arg2)
       (and-still-more-do arg3)]
  arg4)