[aerique]

I'm not trying to start a flamewar here but could you go into why your preference is with Lisp2 instead of Lisp1?

A lot of commenters here have a strong preference to Lisp1's so I'd be happy to hear a different point of view.

(Disclaimer: I'm mostly a CL user and appreciate it being a Lisp2.

Also, nice to see you here! I always really liked your posts in comp.lang.lisp.)

[Grue3]

Not having to name your list variables "lst" is a big one.

[netsettler]

Yes, I am with Grue on this one. The overcrowding of namespaces means the very common case of receiving a thing that is known by its type (list as "list" or "string") occludes a common constructor that you might want and makes you spell it badly. I really very strongly prefer proper spellings of things, but moreover I think this is "natural" in a way that is neglected in this discussion.

Simplicity can be measured in different ways, and there is a tendency in the Scheme community to think of simplicity as a measure of the size of a formal semantics. But two things come to mind about that metric: (1) I have often claimed that small languages make big programs, and big languages make small programs. So to some degree it's the case that tiny languages mean you have to laboriously reconstruct as program or library what the language did not let you do in its zeal to not offer functionality. (2) Human beings are not designed in the Scheme way. The natural languages include no language at all, out of many hundreds, in which words have only one meaning and do not enjoy contextual distinctions. So in my view, simplicity can also measure the lack of dissonance between the program model and the brain model. My brain is, I believe, well-adapted to understand word meanings differently for noun and verb, and Scheme affirmatively chooses not to rely on that, leaving my brain bothered by the lack of ability to use it natural mode and forced to use what seems more cumbersome. I don't want to reach for more words, I want to use obvious context. And I claim that this is at least a valid way of thinking, if not uniquely valid. I'm not trying to disallow the way others think (or think they think, we being poor at actually introspecting sometimes), but to say that the way others think is no more or less valid than my own.

This is, as Aerique implies, somewhat a religious matter and not to be warred over. So I don't want to provoke debate on whether my way is THE right way, only A right way among MANY simultaneously right ways.

At another level, though, this is the very essence of what it is to be a CL user, or a member of the CL community, at least in my mind: The language expressly accommodates and encourages a pluralistic society in which multiple paradigms are simultaneously supported. I don't want to accuse the Lisp1 community of being a bunch of intolerant folks, but I will note that in my mind it's hard to escape the sense that it bears a striking resemblance to that. It's a community that wants people to learn the Scheme way, not a community that wants to accommodate the various ways people naturally think.

I keep coming back to the old joke "There are two kinds of people in the world: People who think there are two kinds of people in the world, and people who don't."

CL has preferred casifications, but expressly goes out of its way to accommodate others. It has ways of thinking about loops in various paradigms. It has macros and read syntax things for letting you override almost any decision that we could figure a way for you to override. There are places where we do a poor job or an incomplete job, but that's more an artifact of the energy and funding than of design. There was pressure to reduce out the redundancy and we opted not to.

People think in multiple namespaces. We know that when you license a production you can create a license (British respelling notwithstanding, it is possible to use the same word in different contexts without confusing whether it is a noun or a verb). In Spanish, a normal speaker would not flinch at the sentence "Como como como." (I eat how I eat, where the middle "como" is "how" and the outer two are "I eat".) These are natural, and so simplicity in this context, at least for me, is being to write thing the way I think.

The imagined need to crowd out these names doesn't really come up in CL. Nouns and verbs mostly operate in different orbits and don't interact, and that feels pretty natural. Languages are more about ecologies than about a la cart features, and there's a danger in liking a feature and thinking it can just be injected into an ecology and will behave either as expected or even just pleasantly.

[kazinator]

Although I'm with you on the issue of some Lisp-1 people being parochial, we can argue that "como como como" is an example of something bad that we don't necessarily want in a programming language. Not everything natural, in natural language, is good in a computer language. Never mind that a word can be a noun and verb in different ways: in natural languages, even if the word has the same role, like noun, it can have different "bindings" at the same time in that same space due to homonyms. Do you want the same symbol to have several completely unrelated global bindings in the same space, the dispatch being resolved based on semantic context (perhaps not even known until run-time)? Ouch.

Simply the fact that you have exactly two namespaces, in each of which there can only be exactly one binding for a symbol at a given lexical level, is different from natural languages.

I'm convinced that Lisp-2 and Lisp-1 have merit, and made a Lisp dialect that offers both, in a reasonable way that manages to be relatively clean.

An ideal Lisp dialect supports the reasonable request of him or her who wants (list list) to Just Work, and it supports that programmer also who has a function-valued variable f and just wants (f x y) to work. That ideal, if taken too literally, is contradictory, but an acceptable compromise is to have [f x y] work, where [] changes the evaluation of atomic forms that are bindable symbols to Lisp-1 style (utterly, with deep support from the macro-expander and evaluation semantics).

[netsettler]

I am totally comfortable with funcall. It is my preference, not something I bargain down to. I don't have a need to have (f x y) "just work". You needn't agree. I acknowledge differing tastes here. But you need to, as well. It is not proper to speak as if we obviously have the same goals. We do not. It is not that we have the same goal and are differing on tactics. We have actually different goals. That is important to see or else you cannot wrap your head around why the issue played out as it did.

As you say, notational games can be played. And there are other approaches. Just because people have different goals doesn't mean that's the end of discussion. But an honest discussion must recognize the legitimate desires of both sides without disparaging one side. Getting inside another's head is important.

I don't pass functional arguments a lot. CL programmers often don't. Where Scheme would pass functions, CL often uses keyword arguments. In sort, for example, we customize behavior not by passing some function but by passing a list of keywords. There are places we pass functions, but it is not our ordinary business. So calling it out, by doing (funcall list...) rather than just (list...) gives a signal that something unusual is happening. If you plan for this not to be unusual, you will go a different way. But we do not all aspire to pass functions at every point. I like having it for certain purposes, but doing things in other ways as well.

For another take on a middle ground than the character syntax you describe, see my http://www.nhplace.com/kent/Half-Baked/spiel/index.html

[netsettler]

> Do you want the same symbol to have several completely unrelated global bindings in the same space

Absolutely. Yes.

[kazinator]

Are you sure? Global, in the same space? As in X having three different bindings as (say) a variable, at the same environmental level ("top-level")?

[netsettler]

Thanks. Not sure how notifications work here, but I replied to your comment as a reply to Grue below this, so check the page.