> If YOUR brain can process textual words as fast as symbols, that's wonderful, but may be specific to you
Most people can do that. Most text people read just consists of words. Actually reading text with special symbols is quite complex - especially if the meaning depends on a mix of prefix, infix, postfix with different operator precedence.
> And sure there are standards/conventions in Lisp, but the competition also has standards/conventions such that it's not a difference maker in comparisons.
You claim a difference. I claim, you are just unfamiliar with Lisp.
> The difference maker is WORDS alone versus words + symbols.
No, the difference is words and structure.
Take for example the usual imperative code:
a := 3;
b := a*4;
if a > b
print a
else
print b
...
That's just a vertical sequence without much structure. You can add more { and }, but the shape largely stays the same.
Lisp code would look like this:
(let* ((a 3)
(b (* a 4)))
(if (> a b)
(print a)
(print b)))
That's much more tree-like:
LET*
binding
binding
BODY
BODY
BODY
From that we can easily see that this is a new scope, what modifies the scope and what extent the scope has.
Lisp users learn to parse these visual and structural blocks & patterns. Once one has learned the vocabulary of basic code patterns, it's getting much easier to read Lisp.
They both have structure so it's not a difference maker in comparisons.
> Most people can do that. Most text people read just consists of words.
Yes, but "do" and "do better than alternatives" are different things. I already gave examples of possible alternatives/enhancements to typical English text that would help at least my brain. I won't reinvent that sub-discussion here.
> That's much more tree-like:
Being tree-like and being easier to read are not necessarily the same thing.
> I claim, you are just unfamiliar with Lisp.
How long do you believe it's realistic to keep at it if the benefits come slow? For example, if I keep coding in Lisp heavily for 2 years and STILL find it sluggish to read, is it realistic to then give up in your book?
> From that we can easily see that...
Who is this "we"?
I've been reading words and symbols for multiple decades in various contexts (programming, regular books, etc.). I've concluding after these decades that if used in the right spots, symbols GREATLY ENHANCE my ability to parse/grok/absorb written material IRREGARDLESS of the domain or the specific language.
For example, one thing I like from C# over VB.net is that C# uses square brackets for array indexes instead of parenthesis like VB does. It improved my head's groking speed of array-related code because parentheses have multiple meanings in VB. (I'm not claiming C# is overall better, this is just one aspect.)
Symbols MIXED with words (well) enhance the absorption of words. It's a ying-yang kind of thing. They COMPLIMENT each other. I truly doubt a billion years of using mostly just one OR the other will prove better than using them both.
Sorry, I believe Lisp is just plain lacking there. I want my ying-yang MTV. Go play your Wordy Gurdy in Jennifer's juniper garden.
> They both have structure so it's not a difference maker in comparisons.
Why not? structure can be different, example: shallow vers. deep. That both have some structure, that in both it's the same structure and that it is expressed in the same way.
> Being tree-like and being easier to read are not necessarily the same thing.
I did not claim that it is the same thing.
> How long do you believe it's realistic to keep at it if the benefits come slow?
You look for reasons not to learn it. You already KNOW that it will take years and will show no result.
> I've concluding after these decades
That makes little sense. After long and intense training lots of things look easy: juggling, flying a helicopter, ...
Unfortunately you haven programmed in Lisp and thus you have no idea about how difficult it would be to learn it.
I have also learned first to code in hex codes, assemblers, BASIC, Pascal, Modula, etc. Still I can read Lisp code just fine.
> I believe Lisp is just plain lacking there
You believe it, before even tried to learn Lisp and understand the difference.
You believe that a hammer is difficult to use, but you have only seen one, not hammered with it.
> I did not claim that [tree-like and easy-to-read] is the same thing.
Your example implied it. If you meant something different, it wasn't explicitly stated. There are multiple factors that play into "easy to read", and they often differ per person. Tree-ness helps in some cases, but not others, or can be over-done.
> After long and intense training lots of things look easy
But reading words PLATEAUS in most people. You can't throw time at it to speed it up much. "Speed reading" courses don't improve comprehension of details, only summary skimming speed.
> I have also learned first to code in hex codes, assemblers, BASIC, Pascal, Modula, etc. Still I can read Lisp code just fine.
I'm not sure what point you are trying to make here.
> Unfortunately you haven programmed in Lisp and thus you have no idea about how difficult it would be to learn it.
I dabbled it in many years ago, and just found it hard to read and didn't see that exposure time was paying off in the speed compared to learning/reading other tools/languages. Groking it faster either has a long learning curve, or is the "hockey stick curve" I mentioned earlier.
You haven't explained why it has that comparatively slow ramp up and why I should accept the slow grok start compared to other tools. If it does have the hockey stick grok curve, it stands out unique in that regard and there should be a good reason behind that, yet strangely nobody knows why. You appear to be avoiding these key questions/puzzles. I don't understand why. If you want to promote Lisp, you better start caring about this decades-old conundrum: it's not going away. "Just keep it at forever" is NOT a good answer.
> You believe that a hammer is difficult to use, but you have only seen one, not hammered with it.
After many decades I have a pretty good feel for what kinds of tools, symbols, layouts, and UI's work best for MY eyes and brain. I'm not going to force things for 10+ years to see if my assessment rules of thumb are actually wrong for specific tools. That's not a rational use of anybody's time.
And MANY others have said the same about Lisp, and it has yet to catch on in the mainstream despite being around 60 years and tried in many projects. It does fine in certain niches and continues to do fine in those niches. But if you keep failing mainstream beauty pageants for 60 years, common sense should tell you that the public just plain finds you ugly. Get a clue already! Lisp has buck teeth and a big nose. You may have a thing for buck teeth, but your brain is not a representative specimen of humanity.
Further, there's nothing to force people to use good Lisp style and formatting. If it did go mainstream, more would probably abuse and misuse it. Fans treat their prized possession with care, others don't. Nice things that happen in Nicheville don't scale to big cities.
And structure.
> If YOUR brain can process textual words as fast as symbols, that's wonderful, but may be specific to you
Most people can do that. Most text people read just consists of words. Actually reading text with special symbols is quite complex - especially if the meaning depends on a mix of prefix, infix, postfix with different operator precedence.
> And sure there are standards/conventions in Lisp, but the competition also has standards/conventions such that it's not a difference maker in comparisons.
You claim a difference. I claim, you are just unfamiliar with Lisp.
> The difference maker is WORDS alone versus words + symbols.
No, the difference is words and structure.
Take for example the usual imperative code:
That's just a vertical sequence without much structure. You can add more { and }, but the shape largely stays the same.Lisp code would look like this:
That's much more tree-like: From that we can easily see that this is a new scope, what modifies the scope and what extent the scope has.Lisp users learn to parse these visual and structural blocks & patterns. Once one has learned the vocabulary of basic code patterns, it's getting much easier to read Lisp.