Yey for python for stepping forward on this issue, minus points for their incorrect approach to (multiline) anonymous functions.
(I know people will flame this and assume I'm trolling, but this is just my POV as someone who's programed in LISP and ~10 other languages for 20 years now).
You still gotta read the code later. It's not just about input time. The () just cloud things up and can make it slower to understand what's going on IMHO.
This is just my opinion/brain, but I also dislike the RP-style notation. 3 + 5 is easier for me to read than + 3 5, especially when you start combining things like (/ 15 (* (+ 3 5) 4)).
I do agree partially about the math, though. (+ 1 2 3 4 5 6 7) is easier to read for me than 1 + 2 + 3 + 4 + 5 + 6 + 7, but most mixed-operation expressions are easier to human-read infix.
S-expressions are also more explicit, eschewing punctuation for an AST representation of code. For example, a[2] becomes (aref a 2). Yes, this explicitness is more verbose, but because it's more regular I'd say it's easier to read when things get complex.
However, once you taste the ability to programmatically generate source code right in your code itself, and that becomes part of your common workflow, the benefits of AST s-expressions blow away any of these relatively minor downsides. You can code in an idealized representation, then macro that ideal into actual executing code.
http://www-cgi.cs.cmu.edu/afs/cs/project/ai-repository/ai/la...
Check out the book 'Paradigms of Artificial Intelligence Programming' by Peter Norvig. It is one of the best books ever written about programming and it explains a lot of Common Lisp.
You should have no problems reading this code a week later, a year later or ten years later...
- It should be aware of S-expression grammar, and actively monitor what the user is typing. (Think of it as an s-expression expert watching over your shoulder).
- The line or code block that the cursor is on at a given time, could swtich to multiline view on the fly, with parentheses replaced with indentations, and some color coding. When you move cursor up using the arrow key, the multiline S-expression automatically collapses, and the one above expands.
In any case, text editors need to be "fully" aware of the language, e.g., even if the editor does syntax highlighting, it is doing that based on the complete parsing cabability of the syntax, instead of just bunch of rules in editor's script (like vimscript in vim).
It would also help if the source file is saved as an AST of the code, instead of raw code. This would also help with code formatting on the fly, and personalized settings for the user of the text editor (e.g., one use always prefers to see S-expressions in multiple lines, another always prefers collapsed view.)
Going further. Text editor should allow you to replace any language token with your favorite token, e.g., '(' and ')' could be replaced with '{' or '}' or something else (or maybe even just indentations). As a user preference, not as something that is saved in the AST file.
I hope to see something like this for C, something that I like to call "semantic C" programming.
I guess I went off on a tangent.
Edit: I forgot to add that whatever the disadvantages of Lisp-style syntax, saying it has to die is ridiculous. It is sufficiently useful that it has survived all of these years, and will continue to survive for a long time.
And as for Python's multiline lambdas... I'll be a lambda heretic and say list comprehensions are the superior approach.
If all you use lambdas for is list comprehensions then... sure?
Another one that sort of resembles Lisp in ALGOL's clothing, is Dylan: http://opendylan.org/
Edit: Why the down vote? I appreciated someone's work to address the issues I have with LISP?!